Search

Fire-code inspection and compliance are among the highest priorities for fire-inspection agencies to reduce the loss of life and property that can result from fire incidents. Requirements for code compliance and inspection vary throughout towns and states within the United States, and building owners who violate these codes can be penalized via fines and mandated compliance measures. To the best of our knowledge, no previous study has investigated the strategic behavior of players in a fire-code inspection process. This paper fills the gap by presenting the game-theoretic approach to modeling building owners’ behaviors with respect to fire-code compliance and the inspection strategies of fire-inspection agencies. Both a decentralized model (sequential game in which the fire-inspection agency moves first) and a centralized model (simultaneous game controlled by one central decision maker) are developed to identify the best inspection strategies for the agency and the best compliance strategies for the building owner. This study provides prescriptive insights that can enable policymakers to improve fire-code compliance and inspection by identifying the conditions that motivate the players to participate positively in the inspection and compliance processes. Numerical sensitivity analyses of the equilibrium strategies and the expected losses of the players are provided, along with a comparison of the results between the decentralized and centralized models.

Security vulnerability prediction (SVP) can identify potential vulnerable modules in advance and then help developers to allocate most of the test resources to these modules. To evaluate the performance of different SVP methods, we should take the security audit and code inspection into account and then consider effort-aware performance measures (such as $ACC$ and $P_{\rm opt}$ ). However, to the best of our knowledge, the effectiveness of different SVP methods has not been thoroughly investigated in terms of effort-aware performance measures. In this article, we consider 48 different SVP methods, of which 36 are supervised methods and 12 are unsupervised methods. For the supervised methods, we consider 34 software-metric-based methods and two text-mining-based methods. For the software-metric-based methods, in addition to a large number of classification methods, we also consider four state-of-the-art methods (i.e., EALR, OneWay, CBS, and MULTI) proposed in recent effort-aware just-in-time defect prediction studies. For text-mining-based methods, we consider the Bag-of-Word model and the term-frequency-inverse-document-frequency model. For the unsupervised methods, all the modules are ranked in the ascendent order based on a specific metric. Since 12 software metrics are considered when measuring extracted modules, there are 12 different unsupervised methods. To the best of our knowledge, over 40 SVP methods have not been considered in previous SVP studies. In our large-scale empirical studies, we use three real open-source web applications written in PHP as benchmark. These three web applications include 3466 modules and 223 vulnerabilities in total. We evaluate these SVP methods both in the within-project SVP scenario and the cross-project SVP scenario. Empirical results show that two unsupervised methods [i.e., lines of code (LOC) and Halstead's volume (HV)] and four recently proposed state-of-the-art supervised methods (i.e., MULTI, OneWay, CBS, and EALR) can achieve better performance than the other methods in terms of effort-aware performance measures. Then, we analyze the reasons why these six methods can achieve better performance. For example, when using 20% of the entire efforts, we find that these six methods always require more modules to be inspected, especially for unsupervised methods LOC and HV. Finally, from the view of practical vulnerability localization, we find that all the unsupervised methods and the OneWay method have high false alarms before finding the first vulnerable module. This may have an impact on developers’ confidence and tolerance, and supervised methods (especially MULTI and text-mining-based methods) are preferred.

Code Inspection is a validation process widely used to improve the quality of software. To streamline this process and decrease the possibility of human error, improving the reliability of inspection results, it is possible to use specialized automated code inspection tools. Thus, this article proposes to analyze code inspection tools for PHP programming language, freely available on Github Marketplace. To achieve this goal, the GLPI system was chosen to be inspected, in addition, four code inspection tools were selected, out of twenty-eight available. Criteria were used for the tools selection, consistent with the sytem profile to be inspected and that do not have limitations on the inspection result. To classify the results obtained, the Common Weakness Enumeration (CWE) was used, a list of software and hardware weaknesses developed by numerous renowned companies, such as Microsoft, Apple and IBM. As a result of the inspection work, we found more than ten thousand failures divided into thirty-four different CWEs and from these we analyzed the individual feedback of each tool, as each one of them had unique advantages and disadvantages.

The software inspection process allows identifying defects during the development cycle. In the context of mobile serious games, specific inspection checklists can be employed to guarantee their quality. However, there are few tools to support the use of these checklists and the existing ones are generic and not specific for the evaluation of digital educational games for mobile devices. To assist software engineers in the evaluation of this type of games, an open-source desktop tool was developed in C#, called TIMEG (Tool for Checklist Inspection of Mobile Educational Games). TIMEG allows to: (1) embed inspection checklists; (2) point out defects based on the items in the checklists; (3) generate inspection reports; and if the game is already available in the Google Play store, (4) present information about the users’ opinions. The tool was evaluated from the point of view of inexperienced software engineers when applied for evaluating a mobile serious game; and through the answers to a questionnaire. The results indicate that the tool was perceived as useful and easy to use, in addition to identifying opportunities for improvement in the tool’s interface and usability, as well as improvements in the presentation of relevant information in the defect reports. Link para Video: Clique Aqui

Regression testing is the activity performed by developers to check whether new modifications have not introduced bugs. A crucial requirement to make regression testing effective is that test cases are deterministic. Unfortunately, this is not always the case as some tests might suffer from so-called flakiness, i.e., tests that exhibit both a passing and a failing outcome with the same code. Flaky tests are widely recognized as a serious issue, since they hide real bugs and increase software inspection costs. While previous research has focused on understanding the root causes of test flakiness and devising techniques that automatically fix them, in this paper we explore an orthogonal perspective: the relation between flaky tests and test smells, i.e., suboptimal development choices applied when developing tests. Relying on (1) an analysis of the state-of-the-art and (2) interviews with industrial developers, we first identify five flakiness-inducing test smell types, namely Resource Optimism, Indirect Testing, Test Run War, Fire and Forget, and Conditional Test Logic, and automate their detection. Then, we perform a large-scale empirical study on 19,532 JUnit test methods of 18 software systems, discovering that the five considered test smells causally co-occur with flaky tests in 75% of the cases. Furthermore, we evaluate the effect of refactoring, showing that it is not only able to remove design flaws, but also fixes all 75% flaky tests causally co-occurring with test smells.

Software bug prediction techniques can be very helpful in testing and code inspection. Over the past decade, network measures have been successfully used in bug prediction. Following the same intuition, recently, researchers started using network embedding techniques in bug prediction. However, existing studies only evaluated the Skip-gram and CBOW models with random walk. Considering network embedding is a fast-developing research direction, it is important to evaluate other network embedding techniques’ performances in bug prediction. Moreover, existing studies have not investigated the application and performance of network embedding in effort-aware bug prediction, which is thought to be a more realistic scenario that evaluates the cost effectiveness of bug prediction models. In this paper, we conduct an extensive empirical study to evaluate network embedding algorithms in bug prediction by utilizing and extending node2defect, a newly proposed bug prediction model that combines the embedded vectors with traditional software engineering metrics through concatenation. Experiments are conducted based on seven network embedding algorithms, two effort-aware models, and 13 open-source Java systems. Experimental results show that node2defect outperforms traditional metrics by + 14.64% in terms of MCC score, and by + 7.51% to + 16.57% in effort-aware bug prediction. More interestingly, when combined with CBS + , the embedded vectors alone can achieve the best performance. Among different network embedding algorithms, the newly proposed algorithm ProNE has the best performance.

Effort-aware Just-in-Time (JIT) defect identification aims at identifying defect-introducing changes just-in-time with limited code inspection effort. Such identification has two benefits compared with traditional module-level defect identification, i.e., identifying defects in a more cost-effective and efficient manner. Recently, researchers have proposed various effort-aware JIT defect identification approaches, including supervised (e.g., CBS+, OneWay) and unsupervised approaches (e.g., LT and Code Churn). The comparison of the effectiveness between such supervised and unsupervised approaches has attracted a large amount of research interest. However, the effectiveness of the recently proposed approaches and the comparison among them have never been investigated in an industrial setting. In this paper, we investigate the effectiveness of state-of-the-art effort-aware JIT defect identification approaches in an industrial setting. To that end, we conduct a case study on 14 Alibaba projects with 196,790 changes. In our case study, we investigate three aspects: (1) The effectiveness of state-of-the-art supervised (i.e., CBS+,OneWay, EALR) and unsupervised (i.e., LT and Code Churn) effortaware JIT defect identification approaches on Alibaba projects, (2) the importance of the features used in the effort-aware JIT defect identification approach, and (3) the association between projectspecific factors and the likelihood of a defective change. Moreover, we develop a tool based on the best performing approach and investigate the tool's effectiveness in a real-life setting at Alibaba.

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.

Developers often make recurring changes, similar but different changes across multiple locations. They inspect such code changes per source file (i.e., a diff patch) during code reviews; however, diff patches represent low-level code modification without summarizing recurring changes, leading to tedious and error-prone code inspection. To address this problem, we propose a novel code review approach, Recurring Code Changes Inspection with Deep Learning (RIDL) that leverages change patterns of an edit script by learning code clones, identical or nearly similar code fragments. To train a classifier, RIDL learns 13,940 clones with four different clone types (e.g., Type-1, Type-2, Type-3, and Type-4 clones) from a clone database mined from 25,000 subject programs. Our approach then leverages the classifier to (1) interactively summarize recurring changes and (2) detect change mistakes, potential anomalies in a given codebase. In the evaluation, after 2 hours of training, RIDL analyzes code changes in four open source projects. It summarizes recurring changes with 95.1% accuracy and detects change anomalies with 93.1% accuracy. Our results show that RIDL should help developers effectively inspect recurring changes during code reviews.

The massive adoption of Machine Learning (ML) has deeply changed the internal structure, the design and the operation of software systems. ML has shifted the focus from code to data, especially in application areas where it is easier to collect samples that embody correct solutions to individual instances of a problem, than to design and code a deterministic algorithm solving it for all instances. There is an increasing awareness of the need to verify key non-functional properties of ML-based software applications like fairness and privacy. However, the traditional approach trying to verify these properties by code inspection is pointless, since ML models’ behavior mostly depends on the data and parameters used to train them. Classic software certification techniques cannot solve the issue as well. The Artificial Intelligence (AI) community has been working on the idea of preventing undesired behavior by controlling a priori the ML models’ training sets and parameters. In this paper, we take a different, online approach to ML verification, where novel behavioral monitoring techniques based on statistical testing are used to support a dynamic certification framework enforcing the desired properties on black-box ML models in operation. Our aim is to deliver a novel framework suitable for practical certification of distributed ML-powered applications in heavily regulated domains like transport, energy, healthcare, even when the certifying authority is not privy to the model training. To achieve this goal, we rely on three key ideas:(i)use test suites to define desired non-functional properties of ML models,(ii)Use statistical monitoring of ML models’ behavior at inference time to check that the desired behavioral properties are achieved, and(iii)compose monitors’ outcome within dynamic, virtual certificates for composite software applications.

Rust’s ownership type system enforces a strict discipline on how memory locations are accessed and shared. This discipline allows the compiler to statically prevent memory errors, data races, inadvertent side effects through aliasing, and other errors that frequently occur in conventional imperative programs. However, the restrictions imposed by Rust’s type system make it difficult or impossible to implement certain designs, such as data structures that require aliasing (e.g. doubly-linked lists and shared caches). To work around this limitation, Rust allows code blocks to be declared as unsafe and thereby exempted from certain restrictions of the type system, for instance, to manipulate C-style raw pointers. Ensuring the safety of unsafe code is the responsibility of the programmer. However, an important assumption of the Rust language, which we dub the Rust hypothesis, is that programmers use Rust by following three main principles: use unsafe code sparingly, make it easy to review, and hide it behind a safe abstraction such that client code can be written in safe Rust. Understanding how Rust programmers use unsafe code and, in particular, whether the Rust hypothesis holds is essential for Rust developers and testers, language and library designers, as well as tool developers. This paper studies empirically how unsafe code is used in practice by analysing a large corpus of Rust projects to assess the validity of the Rust hypothesis and to classify the purpose of unsafe code. We identify queries that can be answered by automatically inspecting the program’s source code, its intermediate representation MIR, as well as type information provided by the Rust compiler; we complement the results by manual code inspection. Our study supports the Rust hypothesis partially: While most unsafe code is simple and well-encapsulated, unsafe features are used extensively, especially for interoperability with other languages., Proceedings of the ACM on Programming Languages, 4 (OOPSLA), ISSN:2475-1421

Effort-aware just-in-time (JIT) defect prediction aims at finding more defective software changes with limited code inspection cost. Traditionally, supervised models have been used; however, they require sufficient labelled training data, which is difficult to obtain, especially for new projects. Recently, Yang et al. proposed an unsupervised model (i.e., LT) and applied it to projects with rich historical bug data. Interestingly, they reported that, under the same inspection cost (i.e., 20 percent of the total lines of code modified by all changes), it could find about 12% - 27% more defective changes than a state-of-the-art supervised model (i.e., EALR) when using different evaluation settings. This is surprising as supervised models that benefit from historical data are expected to perform better than unsupervised ones. Their finding suggests that previous studies on defect prediction had made a simple problem too complex. Considering the potential high impact of Yang et al.’s work, in this paper, we perform a replication study and present the following new findings: (1) Under the same inspection budget, LT requires developers to inspect a large number of changes necessitating many more context switches. (2) Although LT finds more defective changes, many highly ranked changes are false alarms. These initial false alarms may negatively impact practitioners’ patience and confidence. (3) LT does not outperform EALR when the harmonic mean of Recall and Precision (i.e., F1-score) is considered. Aside from highlighting the above findings, we propose a simple but improved supervised model called CBS+, which leverages the idea of both EALR and LT. We investigate the performance of CBS+ using three different evaluation settings, including time-wise cross-validation, 10-times 10-fold cross-validation and cross-project validation. When compared with EALR, CBS+ detects about 15% - 26% more defective changes, while keeping the number of context switches and initial false alarms close to those of EALR. When compared with LT, the number of defective changes detected by CBS+ is comparable to LT’s result, while CBS+ significantly reduces context switches and initial false alarms before first success. Finally, we discuss how to balance the tradeoff between the number of inspected defects and context switches, and present the implications of our findings for practitioners and researchers.

Code review has been widely adopted by and adapted to open source and industrial projects. Code review practices have undergone extensive research, with most studies relying on trace data from tool reviews, sometimes augmented by surveys and interviews. Several recent industrial research studies, along with blog posts and white papers, have revealed additional insights on code reviewing “from the trenches.” Unfortunately, the lessons learned about code reviewing are widely dispersed and poorly summarized by the existing literature. In particular, practitioners wishing to adopt or reflect on an existing or new code review process might have difficulty determining what challenges to expect and which best practices to adopt for their development context. Building on the existing literature, this article adds insights from a recent large-scale study of Microsoft developers to summarize the challenges that code-change authors and reviewers face, suggest best code-reviewing practices, and discuss tradeoffs that practitioners should consider. This article is part of a theme issue on Process Improvement.

Context: Fault localization is among the most expensive tasks in software development. Spectrum-based fault localization (SFL) techniques seek to pinpoint faulty program elements (e.g., statements), by sorting them only by their suspiciousness scores. Developers tend to fall back on another debugging strategy if they do not find the bug in the first positions of a suspiciousness list. Objective: In this study, we assess techniques to contextualize code inspection whose goal is two-fold: to provide guidance during fault localization, and to improve the effectiveness of SFL techniques in classifying bugs within the first picks. Code Hierarchy (CH) and Integration Coverage-based Debugging (ICD) techniques provide a search roadmap —a list of methods—that guide the developer toward faults. CH assigns a method with the highest suspiciousness score of its blocks, and ICD captures method call relationships from testing to establish the roadmap. Two new filtering strategies— Fixed Budget (FB) and Level Score (LS)—are combined with ICD and CH for reducing the amount of blocks to inspect in each method. Method: We evaluated the effectiveness of ICD, CH, FB, LS, and a suspiciousness block list (BL) on 62 bugs from 7 real programs. Results: ICD and CH using FB found more faults inspecting less blocks than BL with statistical significance. More than 50% of the faults were found inspecting at most 10 blocks using ICD-FB and CH-FB. Moreover, ICD and CH located 70% of the faults by inspecting, at most, 4 methods. Conclusions: These results suggest that the contextualization provided by roadmaps and filtering strategies is useful for guiding developers toward faults and improves the performance of SFL techniques.

Previous research in defect prediction has proposed approaches to determine which files require additional testing resources. However, practitioners typically create tests at a higher level of abstraction, which may span across many files. In this paper, we study software testing, especially test resource prioritization, from a different perspective. We use topic models to generate topics that provide a high-level view of a system, allowing developers to look at the test case coverage from a different angle. We propose measures of how well tested and defect prone a topic is, allowing us to discover which topics are well tested and which are defect prone. We conduct case studies on the histories of Mylyn, Eclipse, and NetBeans. We find that 34–78% of topics are shared between source code and test files, indicating that we can use topic models to study testing; well-tested topics are usually less defect prone, defect-prone topics are usually undertested; we can predict which topics are defect prone but not well tested with an average precision and recall of 75% and 77%, respectively; our approach complements traditional prediction-based approaches by saving testing and code inspection effort; and our approach is not particularly sensitive to the parameters that we use.

Malware basically means malicious software that can be an intrusive program code or anything that is designed to perform malicious operations on system and executes malicious actions such as clandestine, listening, monitoring, saving, and deleting without the user's knowledge and consent. Malware review and analysis requires an advanced level of programming knowledge, in-depth file systems knowledge, deep code inspection, and reverse engineering capability. New techniques are needed to reduce indirect costs of malware analysis. This paper aims to provide insights into the malware visualization techniques and its applications, most common malware types and the extracted features that used to identify the malware are demonstrated in this study. In this work, Systematic Literature Review (SLR) conducted to investigate the current state of knowledge about Malware detection techniques, data visualization and malware features. An advanced research has been carried out in most relevant digital libraries for potential published articles. 90 preliminary studies (PS) were determined on the basis of inclusion and exclusion criteria. The analytical study is based mainly on the PSs to achieve the goals. The results clarify the importance of visualization techniques and which are the most common malware as well as the most useful features. Several ways to visualize malware to help malware analysts have been suggested.

Context: Software inspection represents an effective way to identify defects in early phase software artifacts, such as models. Unfortunately, large models and associated reference documents cannot be thoroughly inspected in one inspection session of typically up to two hours. Considerably longer sessions have shown a much lower defect detection efficiency due to cognitive fatigue. Goal: The goal of this paper is to propose and evaluate a Model Scoping approach to allow inspecting specific parts of interest in large models. Method: First, we designed the approach, which involves identifying Expected Model Elements (EMEs) in selected parts of the reference document and then using these EMEs to scope the model (i.e., remove unrelated parts). These EMEs can also be used to support inspectors during defect detection. We conducted a controlled experiment using industrial artifacts. Subjects were asked to conduct UML class diagram inspections based on selected parts of functional specifications. In the experimental treatment, Model Scoping was applied and inspectors were provided with the scoped model and the EMEs. The control group used the original model directly, without EMEs. We measured the inspectors’ defect detection effectiveness and efficiency and collected qualitative data on the perceived complexity. Results: Applying Model Scoping prior to the inspection significantly increased the inspector defect detection effectiveness and efficiency, with large effect sizes. Qualitative data allowed observing a perception of reduced complexity during the inspection. Conclusion: Being able to effectively and efficiently inspect large models against selected parts of reference documents is a practical need, in particular in the context of incremental and agile process models. The experiment showed promising results for supporting such inspections using the proposed Model Scoping approach.

Despite being an old language feature, Java exception handling code is one of the least understood parts of many systems. Several studies have analyzed the characteristics of exception handling code, trying to identify common practices or even link such practices to software bugs. Few works, however, have investigated exception handling issues from the point of view of developers. None of the works have focused on discovering exception handling guidelines adopted by current systems -- which are likely to be a driver of common practices. In this work, we conducted a qualitative study based on semi-structured interviews and a survey whose goal was to investigate the guidelines that are (or should be) followed by developers in their projects. Initially, we conducted semi-structured interviews with seven experienced developers, which were used to inform the design of a survey targeting a broader group of Java developers (i.e., a group of active Java developers from top-starred projects on GitHub). We emailed 863 developers and received 98 valid answers. The study shows that exception handling guidelines usually exist (70%) and are usually implicit and undocumented (54%). Our study identifies 48 exception handling guidelines related to seven different categories. We also investigated how such guidelines are disseminated to the project team and how compliance between code and guidelines is verified; we could observe that according to more than half of respondents the guidelines are both disseminated and verified through code inspection or code review. Our findings provide software development teams with a means to improve exception handling guidelines based on insights from the state of practice of 87 software projects., Comment: To appear as full paper in the Proceedings of the 26th International Conference on Software Analysis, Evolution, and Reengineering (SANER 2019)

With increased sophistication of electrical medical devices and more dynamic working environment conditions, safety and accuracy requirements are becoming more strict. Healthcare institutions are challenged in keeping their electrical medical devices safe to use, accurate and reliable in terms of measuring and monitoring of vital parameters. In healthcare institutions maintaining overall operating functions at the required level of performance can be achieved through periodical safety performance inspections. International guidelines, such as Directives IEC 60601, ISO 62353 and MDD 93/42, define how healthcare institutions should perform these periodical checks. In countries, where those guidelines are not adopted, medical device safety and performance inspections are conducted in accordance to Directives of new approach. This paper presents the software solution for tracking the inspection process of medical devices in public and private healthcare institutions. The software is implemented in Oracle Application Development Framework Technology (ADF) and it is used to facilitate gathering of documents such as Inspection Certificates, Working Orders, Measurement Reports, Calculated Errors, and also to keep track of dates for next inspection. The software can be accessed online via Inspection Laboratory website, and all clients, as well as professional laboratory staff can login using their own username and password which makes all inspection data confidential. The software solution is validated in private and public healthcare institutions in Bosnia and Herzegovina (BH). Out of 331 public and private health care institutions in BH, software solution was validated in 218 institutions and more than 1800 inspection tests reports were imported in software by the date that this paper was written.

Software quality is major concern of all the stakeholders either acquirer of the software or supplier of the software. Software inspection is the static verification technique that can contribute to the quality development of the software. As the development trend is focused towards open source software development the smart and light weight techniques are emerged. One of them is modern code review, a light weight software inspection technique. The modern code review is informal, static code analysis performed by small team using collaborative tools. It is argued that modern code review provides benefits other than defect detection and is also subject to various challenges such as lack of trust, communication issues, effective knowledge sharing, personal conflicts and varying situations etc. There has been little research with respect to systematizing and identifying the challenges faced by, and benefits gained by Modern Code Review (MCR) team. There is dire need to recognize and organize these challenges and benefits based on modern code review literature. The aim is to highlight and organize the challenges and benefits regarding modern code review context. It will be beneficial for software quality assurance practitioners and researchers by providing classified list of challenges and benefits.

In this paper, we formalize the defect-prediction problem as a multiobjective optimization problem. Specifically, we propose an approach, coined as multiobjective defect predictor MODEP, based on multiobjective forms of machine learning techniques-logistic regression and decision trees specifically-trained using a genetic algorithm. The multiobjective approach allows software engineers to choose predictors achieving a specific compromise between the number of likely defect-prone classes or the number of defects that the analysis would likely discover effectiveness, and lines of code to be analysed/tested which can be considered as a proxy of the cost of code inspection. Results of an empirical evaluation on 10 datasets from the PROMISE repository indicate the quantitative superiority of MODEP with respect to single-objective predictors, and with respect to trivial baseline ranking classes by size in ascending or descending order. Also, MODEP outperforms an alternative approach for cross-project prediction, based on local prediction upon clusters of similar classes. Copyright © 2015John Wiley & Sons, Ltd.

Background: software inspection results in reviews that report the presence of faults. Requirements author must manually read through the reviews and differentiate between true-faults and false-positives. Problem: post-inspection decisions (fault or nonfault) are difficult and time consuming. It is difficult to employ machine learning (ML) techniques directly to raw (unstructured) data because of class imbalance problem and possible fault-slippage through misclassification of fault. Aim: The aim of this research is to solve this problem with the help of ensemble approach and priority analysis to achieve significant accuracy in determining true-fault and false-positive reviews without losing any listed fault. Method: We conducted empirical experiment using two trained models (with reviews from inspection domain vs. movies domain) to address class imbalance problem. Our approach uses ensemble methods to develop classification confidence of inspection reviews and assigns them to appropriate priority class. Results: The results showed that movies trained model performed better than inspection trained and restricted any possible fault-slippage.

Mining software repositories have frequently been investigated in recent research. Software modification in repositories are often recurring changes, similar but different changes across multiple locations. It is not easy for developers to find all the relevant locations to maintain such changes, including bug-fixes, new feature addition, and refactorings. Performing recurring changes is tedious and error-prone, resulting in in-consistent and missing updates. To address this problem, we present CloneMap, a clone-aware code inspection tool that helps developers ensure correctness of recurring changes to multiple locations in an evolving software. CloneMap allows developers to specify the old and new versions of a program. It then applies a clone detection technique to (1) mine repositories for extracting differences of recurring changes, (2) visualize the clone evolution, and (3) help developers focus their attention to potential anomalies, such as inconsistent and missing updates.

Effort-aware just-in-time (JIT) defect prediction aims at finding more defective software changes with limited code inspection cost. Traditionally, supervised models have been used; however, they require sufficient labelled training data, which is difficult to obtain, especially for new projects. Recently, Yang et al. proposed an unsupervised model (LT) and applied it to projects with rich historical bug data. Interestingly, they reported that, under the same inspection cost (i.e., 20 percent of the total lines of code modified by all changes), it could find more defective changes than a state-of-the-art supervised model (i.e., EALR). This is surprising as supervised models that benefit from historical data are expected to perform better than unsupervised ones. Their finding suggests that previous studies on defect prediction had made a simple problem too complex.Considering the potential high impact of Yang et al.'s work, in this paper, we perform a replication study and present the following new findings: (1) Under the same inspection budget, LT requires developers to inspect a large number of changes necessitating many more context switches. (2) Although LT finds more defective changes, many highly ranked changes are false alarms. These initial false alarms may negatively impact practitioners' patience and confidence. (3) LT does not outperform EALR when the harmonic mean of Recall and Precision (i.e., F1-score) is considered.Aside from highlighting the above findings, we propose a simple but improved supervised model called CBS. When compared with EALR, CBS detects about 15% more defective changes and also significantly improves Precision and F1-score. When compared with LT, CBS achieves similar results in terms of Recall, but it significantly reduces context switches and false alarms before first success. Finally, we also discuss the implications of our findings for practitioners and researchers.

Test case prioritization (TCP) is a practical activity in software testing for exposing faults earlier. Researchers have proposed many TCP techniques to reorder test cases. Among them, coverage-based TCPs have been widely investigated. Specifically, coverage-based TCP approaches leverage coverage information between source code and test cases, i.e., static code coverage and dynamic code coverage, to schedule test cases. Existing coverage-based TCP techniques mainly focus on maximizing coverage while often do not consider the likely distribution of faults in source code. However, software faults are not often equally distributed in source code, e.g., around 80% faults are located in about 20% source code. Intuitively, test cases that cover the faulty source code should have higher priorities, since they are more likely to find faults. In this paper, we present a quality-aware test case prioritization technique, QTEP, to address the limitation of existing coverage-based TCP algorithms. In QTEP, we leverage code inspection techniques, i.e., a typical statistic defect prediction model and a typical static bug finder, to detect fault-prone source code and then adapt existing coverage-based TCP algorithms by considering the weighted source code in terms of fault-proneness. Our evaluation with 16 variant QTEP techniques on 33 different versions of 7 open source Java projects shows that QTEP could improve existing coverage-based TCP techniques for both regression and new test cases. Specifically, the improvement of the best variant of QTEP for regression test cases could be up to 15.0% and on average 7.6%, and for all test cases (both regression and new test cases), the improvement could be up to 10.0% and on average 5.0%.

Managing technical debt includes the detection and assessment of debt at the code and design levels (such as bad smells). Existing approaches and tools for smell detection primarily use static program data for decision support. While a static analysis allows for identifying smell candidates without executing and instrumenting the system, such approaches also come with the risk of missing candidates or of producing false positives. Moreover, smell candidates might result from a deliberate design decision (e.g., of applying a particular design pattern). Such risks and the general ambivalence of smell detection require a manual design and/or code inspection for reviewing all alleged smells.In this paper, we propose an approach to obtain tailorable design documentation for object-oriented systems based on runtime tests. In particular, the approach supports a tool-supported triaging of code-smell candidates. We use runtime scenario tests to extract execution traces. Based on these execution traces, different (automatically derived) model perspectives on method-call dependencies (e.g., dependency structure matrices, DSMs; UML2 sequence diagrams) are then used as decision support for assessing smell candidates. Our approach is implemented as part of the KaleidoScope tool which is publicly available for download.

Researchers have supported the idea of gamification to enhance students' interest in activities like code reviews, change management, knowledge management, issue tracking, etc. which might otherwise be repetitive and monotonous. We performed an experimental study consisting of nearly 180+ participants to measure the impact of gamification on code review process using 5 different code review tools, including one gamified code review instance from our extensible architectural framework. We assess the impact of gamification based on the code smells and bugs identified in a gamified and non-gamified environment as per code inspection report. Further, measurement and comparison of the quantity and usefulness of code review comments was done using machine learning techniques.

Public speaking anxiety is a type of social phobia, which might be commonly seen in novice software engineers. It is usually triggered by a fear of social performance especially when the performer is unfamiliar with the audience. Today, many software engineering activities (e.g. code inspection, peer review, daily meetings, etc.) require social gatherings where individuals need to present their work. However, novice software engineers may not be able to reduce their performance anxiety during their course of education. In this study, we propose a virtual reality approach to construct a practice environment for improving novice software engineers’ pubic speaking experiences. Consequently, we examine the effects of virtual reality intervention on the public speaking experience of six novice software engineers from a computer engineering department. We designed a virtual auditorium to simulate the presentation delivery environment and findings suggest that using this infrastructure for training purposes can reduce presenter anxiety levels – which is consistent with related published studies. We believe that this virtual auditorium environment can deliver benefits for students and practitioners alike in terms of addressing the anxiety that is often associated with early stage career presenters.

Regression testing is a core activity that allows developers to ensure that source code changes do not introduce bugs. An important prerequisite then is that test cases are deterministic. However, this is not always the case as some tests suffer from socalled flakiness. Flaky tests have serious consequences, as they can hide real bugs and increase software inspection costs. Existing research has focused on understanding the root causes of test flakiness and devising techniques to automatically fix flaky tests; a key area of investigation being concurrency. In this paper, we investigate the relationship between flaky tests and three previously defined test smells, namely Resource Optimism, Indirect Testing and Test Run War.We have set up a study involving 19,532 JUnit test methods belonging to 18 software systems. A key result of our investigation is that 54% of tests that are flaky contain a test code smell that can cause the flakiness. Moreover, we found that refactoring the test smells not only removed the design flaws, but also fixed all 54% of flaky tests causally co-occurring with test smells.

Android Malware has emerged as a consequence of the increasing popularity of smartphones and tablets. While most previous work focuses on inherent characteristics of Android apps to detect malware, this study analyses indirect features and meta-data to identify patterns in malware applications. Our experiments show that: (1) the permissions used by an application offer only moderate performance results; (2) other features publicly available at Android Markets are more relevant in detecting malware, such as the application developer and certificate issuer, and (3) compact and efficient classifiers can be constructed for the early detection of malware applications prior to code inspection or sandboxing., Comment: 4 figures, 2 tables and 8 pages

The application of best-practice software inspection processes for early defect detection requires considerable human effort. Crowdsourcing approaches can support inspection activities (a) by distributing inspection effort among a group of human experts and (b) by increasing inspection control. Thus, the application of crowdsourcing techniques aims at making inspection processes more effective and efficient. In this paper, we present a crowdsourcing-supported model inspection (CSI) process and investigate its defect detection effectiveness and efficiency when inspecting an Extended Entity Relationship (EER) model. The CSI process uses so-called Expected Model Elements (EMEs) to guide CSI inspectors during defect detection. We conducted a controlled experiment on defect detection effectiveness, efficiency, and false positives. While CSI effectiveness and efficiency is lower for CSI inspectors, the number of false positives decreases. However, CSI was found promising for increasing the control of defect detection and supports the inspection of large-scale engineering models.

Software diversity is known to improve fault tolerance in N-version software systems by independent development. As the leading cause of software faults, human error is considered an important factor in diversity seeking. However, there is little scientific research focusing on how to seek software fault diversity based on human error mechanisms. A literature review was conducted to extract factors that may differentiate people with respect to human error-proneness. In addition, we constructed a conceptual model of the links between human error diversity and software diversity. An experiment was designed to validate the hypotheses, in the form of a programming contest, accompanied by a survey of cognitive styles and personality traits. One hundred ninety-two programs were submitted for the identical problem, and 70 surveys were collected. Code inspection revealed 23 faults, of which 10 were coincident faults. The results show that personality traits seems not effective predictors for fault diversity as a whole model, whereas cognitive styles and program measurements moderately account for the variation of fault density. The results also show causal relations between performance levels and coincident faults: coincident faults are unlikely to occur at skill-based performance level; the coincident faults introduced in rule-based performances show a high probability of occurrence, and the coincident faults introduced in knowledge-based performances are shaped by the content and formats of the task itself. Based on these results, we have proposed a model to seek software diversity and prevent coincident faults.

nspection is a proven approach that is commonly used to manage software quality. To this end many inspection techniques such as Checklist-Based Reading (CBR), Perspective-Based Reading (PBR), Usage-Based Reading (UBR), and Defect-Based Reading (DBR) have been proposed in the literature. Unfortunately, plethora of empirical studies carried out to evaluate these reading techniques have produced inconsistent and conflicting results. Consequently, ad hoc reading and CBR still remain the standard reading techniques in software organizations. This paper investigates the performance of ad hoc and CBR techniques in a traditional paper-based environment. Seventeen undergraduate students of computer science majority of whom are in their final year were used as subjects in a controlled experiment. Results of the experiment indicate that CBR is significantly superior to ad hoc reading in terms of effectiveness, efficiency, effort, and number of false positives. On the average, 4 faults were detected in 69 minutes using ad hoc reading while 11 faults were detected in 42.5 minutes using Checklist-based reading. Also the average number of false positive is about 3.13 in checklist-based approach as against about 6.44 in ad hoc approach.

In this paper, we present a rigorous comparison of two inspection techniques: our formal method-based approach, SOLIMVA 3.0, with a set of Object-Oriented Reading Techniques (OORTs). We evaluated efficiency (required time to analyse a scenario) and effectiveness (ability to find defects within UML diagrams). Results show that the classical OORT methodology is more efficient than SOLIMVA. However, we found a strong positive correlation between the required time by using OORT and SOLIMVA. For effectiveness, in general, both methodologies presented the same performance. However, SOLIMVA detected more inconsistency (incorrectness and extra information), ambiguity, and partial incompleteness defects while OORT identified more total incompleteness. Our overall conclusion is that a classical reading methodology (OORT) and a formal-based one (SOLIMVA) can be adopted in a complementary way within a software inspection process. While OORT is less costly to apply, SOLIMVA can be used to address some specific types of defects.

Given the increasing importance of soft skills in the computing profession, there is good reason to provide students with more opportunities to learn and practice those skills in undergraduate computing courses. Toward that end, we have developed an active learning approach for computing education called the Pedagogical Code Review (PCR). Inspired by the code inspection process used in the software industry, a PCR is a collaborative activity in which a small team of students, led by a trained moderator: (a) walk through segments of each other's programming solutions, (b) check the code against a list of best coding practices, and (c) discuss and log issues that arise. To evaluate the viability and effectiveness of this approach, we conducted a series of four mixed-method empirical studies of various implementations of PCRs in CS1 courses at Washington State University. The first study validated the viability of the PCR activity. Using a quasi-experimental design, the final three studies evaluated two alternative implementations of PCRs— face-to-face and online . Our results provide evidence that PCRs can promote positive attitudinal shifts, and hone skills in critical review, teamwork, and communication. Based on our findings, we present a set of best practices for implementing PCRs.

One of the most difficult and important software quality assurance/testing tasks is to estimate the expected number of bugs in a given software module or a project. Good estimation methods are important for evaluating the project perform once in an optimized manner and deciding which quality assurance strategies are most appropriate and effective. The core objective of this paper is to define a combined testing strategy to identify the more defects and to validate the testing among code inspection and test driven development (TDD) using open source testing tools. Based on the test rules, evaluating the functionalities and the testing will be done automatically upon user acceptance. After evaluating the test cases, the results will be populated for further development. Though both the testing seem to give effective result in maximum level of testing when conducted individually, the best output by testing can be achieved through the combination of both, TDD and code sniffer testing. Our approach plays a major role in detecting and managing fault present in the software development. Implementation of this methodology proves to be cost effective and saves analyzing time. As a result this shows the improvement in the quality of the product of the software test finally satisfying the customers.

In software product lines (SPL), scoping is a phase responsible for capturing, specifying and modeling features, and also their constraints, interactions and variations. The feature specification task, performed in this phase, is usually based on natural language, which may lead to lack of clarity, non-conformities and defects. Consequently, scoping analysts may introduce ambiguity, inconsistency, omissions and non-conformities. In this sense, this paper aims at gathering evidence about the effects of applying an inspection approach to feature specification for SPL. Data from a SPL reengineering project were analyzed in this work and the analysis indicated that the correction activity demanded more effort. Also, Pareto's principle showed that incompleteness and ambiguity reported higher non-conformity occurrences. Finally, the Poisson regression analysis showed that sub-domain risk information can be a good indicator for prioritization of sub-domains in the inspection activity.

Recent smartphone platforms based on new operating systems, such as iOS, Android, or Windows Phone, have been a huge success in recent years and open up many new opportunities. Unfortunately, 2011 also showed us that the new technologies and the privacy-related data on smartphones are also increasingly interesting for attackers. Especially, the Android platform has been the favorite target for malware, mainly because of the openness of the platform, the ability to install applications from other sources than the Android Market, and the significant gains in market share. Although the processes of detecting and analyzing malware are well known from the PC world, where the arms race between attackers and defenders has continued for the past 15years, they cannot be directly applied to smartphone platforms because of differences in the hardware and software architectures. In this paper, we first give an overview of the current malware situation on smartphone platforms with a special focus on Android and explain relevant malware detection and analysis methods. It turns out that most of the current malware relies on the installation by the user, who represents the last line of defense in malware detection. With these conclusions, we then present a new malware detection method that focuses on the information that the user is able to see prior to the installation of an application-the metadata within the platform's software market. Depending on the platform, this includes the application's description, its permissions, the ratings, or information about the developer. To analyze these data, we use sophisticated knowledge discovery processes and lean statistical methods. By presenting a wide range of examples based on real application metadata extracted from the Android Market, we show the possibilities of the new method. With the possibilities, we argue that it should be an essential part of a complete malware analysis/detection chain that includes other well-known methods such as network traffic analysis, or static, or dynamic code inspection. Copyright © 2013 John Wiley & Sons, Ltd.

Objective: Software development is a multitask activity performed by a team. Each activity involves with different tasks and complexity. To achieve quality of improvement it is important that each activity task should be fault free. But, finding and correcting faults are most expensive and time consuming. Methods: Software inspection is a static analysis technique which does not required program execution, instead it use inspector to make decision during the development. Findings: But it was observed in literature that inspection has bad records in finding accurate defects in software development. In this paper, we present a novel Fault Prediction Approach (FPA) based on the probabilistic model to improvise the software inspection to detect the defect accurately and cost effective for the quality software development. Application/ Improvement: Inspection is an effective activity to find the defects using empirical data in the initial stage of development. The proposed FPA investigate a probabilistic methods using modified Naive Bayes classification to estimate the probable faults in an experiment context to suggest fault controlling development. Further, the analysis investigates how FPA effectively identifying the faults during the inspection and impact in the quality development performance.

A product inspection management system has been developed to meet information management requirements of the inspection process and test data results. An algorithm for extracting empirical report data is proposed, combining the Word generation technology with multi-template application to speed up report editing. In depth study of storage data, queries and statistics functions are realized. System establishment optimizes the inspection process, and provides a safe and stable operation platform for the quality inspection work.

Finding defects efficently is one of the major problems in software development, a problem that often still relies largely on human inspection of code to find defects. Many software development projects use code reviews as a mean to ensure this human inspection occurs. Known as modern code review, this approach is based on tools, such as Gerrit, that help the developers in the reviewing process. As part of this approach, developers are often presented with a list of open code reviews requiring attention; it is left to the developer to find a suitable review on which to work on from a long list of reviews. We present an investigation of two algorithms that recommend an ordering of the list of open reviews based on properties of the reviews. We use a simulation study over the JGit project from the Eclipse Foundation to show that an algorithm based on ordering reviews from least lines of codes changed in the code review to most lines of code out performs other algorithms. This algorithm shows promise for eliminating stagnation of reviews and optimizing the average duration reviews are open.

We propose that understanding functional patterns of activity in mapped brain regions associated with code comprehension tasks and, more specifically, to the activity of finding bugs in traditional code inspections could reveal useful insights to improve software reliability and to improve the software development process in general. This includes helping to select the best professionals for the debugging effort, improving the conditions for code inspections, and identify new directions to follow for training code reviewers. This paper presents an interdisciplinary study to analyze the brain activity during code inspection tasks using functional magnetic resonance imaging (fMRI), which is a well-established tool in cognitive neuroscience research. We used several programs where realistic bugs representing the most frequent types of software faults found in the field were injected. The code inspectors involved in the research include programmers with different levels of expertise and experience in real code reviews. The goal is to understand brain activity patterns associated with code comprehension tasks and, more specifically, the brain activity when the code reviewer identifies a bug in the code ('eureka' moment), which can be a true positive or a false positive. Our results confirmed that brain areas associated with language processing and mathematics are highly active during code reviewing and shows that there are specific brain activity patterns that can be related to the decision-making moment of suspicion/bug detection. Importantly, the activity at the anterior insula region that we find to play a relevant role in the process of identifying software bugs is positively correlated to the precision of bug detection by the inspectors. This finding provides a new perspective on the role of this region on error awareness and monitoring and of its potential predictive value in predicting the quality of bug removing.

Background -- Inspecting requirements and design artifacts to find faults saves rework effort significantly. While inspections are effective, their overall team performance rely on inspectors' ability to detect and report faults. Our previous research showed that individual inspectors have varying LSs (i.e., they vary in their ability to process information recorded in requirements document). To extend the results of our previous LS research, this paper utilizes the concept of eye tracking (to record eye movements of inspectors) along with their LSs to detect reading patterns of inspectors during requirements inspections. Aim -- The objective of this research is to analyze the reading trends of effective and efficient inspectors using eye movement and LS data of individual inspectors and virtual inspection teams. Method -- The current research uses data (LS, eye tracking, and inspection) from thirteen inspectors to find its impact on inspection effectiveness and efficiency. Results -- Results from this study show that, inspectors who detect more faults during inspection, focus significantly more at the fault region to find and report faults as opposed to comprehending requirements information. Results also showed Inspection teams with diverse inspectors outperform similar teams and spend more time in comprehending information at the fault region. Additionally, results showed that inspectors with SEQ LS significantly tends to focus more at fault locations and are preferred for inspection. Conclusion -- These results can aid the selection of inspectors during the inspection process thus improving software quality

Strictly speaking, fault localization includes assessing the code risk of being faulty and identifying the real fault. In practice, only highlighting some possible faulty statements is not helpful enough to reason the roots of the observed failures in a system. Programmers need to manually inspect the highlighted risky statements one by one, reading and understanding their contexts, in order to identify the real faulty ones. However, most related works have been focusing on risk assessment by simply ignoring the fault identification, which makes such techniques much less practical in real world. Therefore, in this paper, we propose a context-aware approach to assist fault comprehension and identification. Built on risk assessment results, our approach searches for the faults on Weighted Call Graph. In our approach the risky statements are re-ordered by function call chains, which can provide much richer information to understand the context and hence reduce the efforts in manual code inspection. Case studies with three open-source systems show that the proposed approach could help to improve the effectiveness of the whole fault localization process.

In order to minimize the most frequent problems in project management, communicability, this paper proposes the application of semiotic inspection method recommended by the semiotic engineering the artifact mental map, the analysis requirements of a software library, the loan requirement by means of experimental research with application of a verification questionnaire communicability in the proposed artifact.

Background: The Capture-recapture (CRC) method has been adopted in software inspection post-inspection defect estimation. One outstanding advantage of the CRC method is that it is able to produce objective estimates without relying on historical data. However, a common impression about the CRC method is its poor performance regarding estimation accuracy with small inspection teams. Involving more inspectors seems to be helpful, yet no conclusive results exist on the reasonable team size in order to get acceptable CRC estimates.Objective: While a number of factors impacting the accuracy of CRC estimation have been identified, in this study, we aim to explore and investigate new reliable and practical factors hence to provide new method to improve the accuracy of CRC estimation.Method: By examining and verifying the fundamental assumption of the CRC method (i.e., the assumption of independence among inspectors), we establish valuable understanding regarding the root cause of the performance of CRC estimation accuracy, based on which we propose a strategy to mitigate the impact derived from violation of the independence assumption and improve the accuracy of CRC estimation.Results: By applying our strategy to remove small portion of inspectors from the original inspection team, we managed to decrease the dependence among inspectors and improve estimation accuracy for the three most popular CRC estimators (i.e., Mt -- CH, Mh -- JK and Mh -- CH, cf. Section 2.1).Conclusions: Our study implies that 'more inspectors, higher accuracy' is not always valid for CRC estimation in software inspection and a independence-driven strategy to select suitable defect data may produce better estimation.

Background: The National HIV/AIDS Strategy calls for active surveillance programs for human immunodeficiency virus (HIV) to more accurately measure access to and retention in care across the HIV care continuum for persons living with HIV within their jurisdictions and to identify persons who may need public health services. However, traditional public health surveillance methods face substantial technological and privacy-related barriers to data sharing. Objective: This study developed a novel data-sharing approach to improve the timeliness and quality of HIV surveillance data in three jurisdictions where persons may often travel across the borders of the District of Columbia, Maryland, and Virginia. Methods: A deterministic algorithm of approximately 1000 lines was developed, including a person-matching system with Enhanced HIV/AIDS Reporting System (eHARS) variables. Person matching was defined in categories (from strongest to weakest): exact, very high, high, medium high, medium, medium low, low, and very low. The algorithm was verified using conventional component testing methods, manual code inspection, and comprehensive output file examination. Results were validated by jurisdictions using internal review processes. Results: Of 161,343 uploaded eHARS records from District of Columbia (N=49,326), Maryland (N=66,200), and Virginia (N=45,817), a total of 21,472 persons were matched across jurisdictions over various strengths in a matching process totaling 21 minutes and 58 seconds in the privacy device, leaving 139,871 uniquely identified with only one jurisdiction. No records matched as medium low or low. Over 80% of the matches were identified as either exact or very high matches. Three separate validation methods were conducted for this study, and they all found ≥90% accuracy between records matched by this novel method and traditional matching methods. Conclusions: This study illustrated a novel data-sharing approach that may facilitate timelier and better quality HIV surveillance data for public health action by reducing the effort needed for traditional person-matching reviews without compromising matching accuracy. Future analyses will examine the generalizability of these findings to other applications. [JMIR Public Health Surveill 2016;2(1):e3]

Do you use software peer reviews? Are you happy with your current code review practices? Even though formal inspection is recognized as one of the most effective ways to improve software quality, many software organizations struggle to effectively implement a formal inspection regime. Open source projects use an agile peer review process-based on asynchronous, frequent, incremental reviews that are carried out by invested codevelopers-that contrasts with heavyweight inspection processes. The authors describe lessons from the OSS process that transfer to proprietary software development. They also present a selection of popular tools that support lightweight, collaborative, code review processes and nonintrusive metric collection.

Thinking process development diagram is a graphical expression from which readers can easily find not only the hierarchy of a given problem but the relationship between the problem and the solution. Although that has been developed as an idea creation support tool in the field of mechanical design, we referred to the restricted version as clamshell diagram to attempt to apply to other fields. In this paper we propose the framework for drawing the diagram of the SQL statement. The basic idea is to supply the hierarchical code fragments of a given SQL statement in the left side of the diagram and to put the meaning written in a natural language in the right. To verify the usefulness of the diagram expression, we actually drew several clamshell diagrams. For three SQL statements that are derived from the same specification, the resulting diagrams enable us to understand the difference visually.

One of the challenges faced by the users of automated visual inspection (AVI) systems is how to efficiently upgrade the legacy systems to inspect the new components introduced into the assembly lines. If the AVI systems are not flexible enough to accommodate new components, they will be rendered obsolete even by small changes in the product being inspected. The overall objective of the research presented in this paper is to produce the methodological basis that will result in the development of highly reconfigurable AVI systems. In this paper, we focus on part of this overall development, the adaptation of preexisting inspection algorithms to inspect similar components introduced into the assembly line. While this paper bases its development and discussion on the inspection of surface mounted devices (SMDs), the proposed methodology is general enough to be applicable to a broad range of inspection problems. In this paper, we present a methodology that would allow the automation of the refinement of AVI algorithms. In particular, the proposed method identifies a set of components, or cluster of components, for which a particular set of inspection features or algorithms, renders a certain level of inspection reliability. This is particularly useful for adapting preexisting systems to inspect new components, especially when the characteristics of the new components are similar to those of components already inspected by the inspection system. We applied this methodology to a case of study of the inspection of SMDs.