Search

Software inspection is considered a cost-effective quality assurance technique in software process improvement. Although inspections detect the majority of defects in the early stages of the development process, this technique is not a common practice in the software industry, especially in small and medium enterprises. In this paper, we propose a model for the inspection process intended to be applicable and acceptable to both small and medium enterprises and large software organisations. The model was implemented in two organisations: one in a medium-scale company and the other one in a department of a big company where its feasibility and benefits were confirmed. A comparison with recent alternative inspection models has also been performed showing the practicality of the proposal and ease of adoption and cost-effectiveness. Copyright © 2014 John Wiley & Sons, Ltd.

Repairing a defect in the late phases of software development can be a hundred times more expensive than finding and fixing it during the requirements and design phase. Software inspection is a technique that may be used to aid in the identification of defects during early stages of the process and avoid propagation of such defects to later phases. The cost-benefit of inspections may be significant if they are efficiently performed. Since this process is affected by several quality factors, the analysis of the overall context of inspection may become complex. Project managers are reluctant to introduce inspection due to uncertainty regarding its real benefits. This paper presents a system dynamics model, which is a descriptive technique for systems modeling and simulation and involves several variables that strongly influence inspection efficiency. The influence levels of model variables are quantified based on real or empirical experiments reported in the literature, in order to approximate model results to values that would be obtained in the real world. The model allows the reproduction of scenarios without paying the costs and facing the risks of a real project implementation. Therefore, it enables the analysis of inspection effects on the software development process.

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.

Context: Capture-recapture approach has been adopted in software inspection for decades for estimating remaining defects and supporting post-inspection decisions. A number of capture-recapture models and estimators have been borrowed from other disciplines (e.g., Biology and social sciences) and applied in software inspections. These models and estimators were created with different assumptions and the violation to these assumptions may lead to invalid application. Most of the reported empirical evaluations of the capture-recapture models and estimators used relatively small data sets (i.e., Small number of inspectors and/or defects), which leads varying conclusions. Objective: The research reported in this paper aims to better understand this approach for software inspection, and the efficacy of the models and estimators in particular, with large data sets. Method: We carried out an empirical study that evaluated several typical capture-recapture estimators (i.e., M0-ML, Mt-ML, Mt-CH, Mh-CH and Mh-JK). The study employed 57 student inspectors in reviewing software requirement specification and formed 1000 virtual teams at each team size in the post statistic testing. Results: The data analysis indicates that: 1) M0-ML and Mt-ML could not generate accurate estimates even with many inspectors. 2) All estimators suffer high level of failure rate with few inspectors. 3) For a small team, estimator Mh-CH performs the best, while with many inspectors, Mt-CH and Mh-JK perform better regarding the accuracy and the failure rate. Conclusion: Our work reveals that no estimator was superior to others under all situations. With an increased team size, estimates generated by estimator Mt-CH and Mh-JK turn to be more accurate than others. While, M0-ML and Mt-ML are able to offer reference value to support post-inspection because of their convergent underestimates.

Software inspections are most widely used technique by industrial practitioners for improving software quality. While inspections are an effective verification technique, evidence suggests that overall performance of an inspection process is highly dependent on an individual inspectors' ability to detect faults. Our work leverages cognitive science research to help improve the inspection team performance. This paper presents the results from two industrial studies that evaluate the effect of cognitive learning styles (LSs) of individual inspectors on their inspection team performance. The results showed that the inspection teams formed with inspectors of diverse LSs outperformed teams with similar LSs of inspectors. These results can help software managers better staff inspectors, enabling cost savings, and improving quality.

There is a great need to assure and improve the reliability and quality of software. Software inspections were introduced over 30 years ago as an answer for this need and they have inspired a lot of research covering many different kinds of aspects. There is a need for an up-to-date survey revealing the current state and the overall evolution of the most prominent research on the area. This paper presents a comprehensive survey focusing on the most relevant 16 interna- tional high-impact scientific publication series. There are 153 articles included in the survey covering both technical and management aspects. The main results include a description of the research trends during 1980-2008 and a description of the main results of the included studies. The description is organized based on a taxonomy of the inspection research as having emerged based on the survey. At general level the surveyed research provides clear evidence that inspections gen- erally benefit software development and quality assurance. There are several proposed theoretical variations for the in- spection process but also many empirical studies. Although the conducted research is relatively scattered, proper science- based understanding about some of the most studied issues has been achieved. Our main conclusion is that conducting empirical research needs to be continued in order to validate the effects of the different kinds of proposed theoretical con- structs in practice. Empirical studies are needed especially in order to better understand the proper implementation and the actual impacts of applying inspections in different kinds of industrial and organizational settings.

Concrete guidelines are often helpful when planning software process improvement. Small companies, in particular, need detailed and unambiguous instructions detailing what process areas to improve, and how to achieve the improvement. This article introduces a set of patterns to direct the improvement of the software inspection process. The pattern approach has been applied, since it has been used very successfully for knowledge-sharing purposes and other areas of software engineering. The approach involves an evaluation of the inspection process capability, setting an overall goal for the improvement and updating the process according to pre-defined actions. Experiments with initial patterns show that the method provides a feasible and quick way of making inspections more effective. Using patterns may also be beneficial when launching more wide-ranging SPI activities, as companies can run preliminary trials of the improvement process on a smaller scale first. Copyright © 2005 John Wiley & Sons, Ltd.

Software inspection is recognized as an effective verification technique. Despite this fact, the use of inspection is surprisingly low. This paper describes a new inspection technique, called task-directed inspection (TDI), and a light-weight process, that were used to introduce inspection in a particular industrial environment. This environment had no history of inspections, was resistant to the idea of inspection, but had a situation where confidence in a safety-related legacy suite of software had to be increased. The characteristics of TDI are explored. They give rise to a variety of approaches that may encourage more widespread use of inspections. This paper examines the industrial exercise as a case study, with the intent that it be useful in other situations that share characteristics with the situation described.

Software inspection is accepted as an effective technique in the battle against defects. However, many organizations fail to maximize these benefits because, for example, the inspection team has difficulty setting exit or re-inspection criteria. This should ideally be based upon an estimate of the number of remaining defects in the source document. It is proposed that a subjective estimate of these remaining defects from individual inspectors can be an effective method for estimating the number of remaining defects, and hence it can be utilized as a mechanism to implement the exit or re-inspection decision.

Software inspection is a valuable technique for defect detection. Recent research has considered the development of computer support, with the aim of providing even greater benefits when applying inspection. This has resulted in the development of a number of prototype support systems. These suffer from some fundamental limitations, however. Asynchronous/Synchronous Software Inspection Support Tool (ASSIST) is designed to tackle these limitations and to provide a platform for rigorous investigation of the inspection process. It uses a custom-designed language known as Inspection Process Definition Language to allow support of any inspection process, and provides an open, expandable system allowing multiple document types to be catered for easily. A number of facilities designed to enhance the inspection process are also present.

This paper discusses a novel active learning exercise which teaches students how to perform and assess the effectiveness of formal software inspections. In this exercise, students are responsible for selecting an artifact from their senior capstone design projects. The students then use fault injection to strategically place faults within the artifact that should be caught by the inspection exercise. Based on the needs of the team, students prepare an inspection packet consisting of a set of inspection instructions, applicable checklists, and the inspection artifact. Students then “hire” a set of inspectors based on classmates' backgrounds and experiences. The team leader then holds two inspection meetings and reports the results. The results are then used to assess the effectiveness of the inspection. Overall, in analyzing 5 years worth of data from this exercise, it is found that students are capable of selecting appropriate materials for inspection and performing appropriate software inspections. The yield of students is lower than an experienced professional might have and the inspection rates tend to be slightly higher than desired for their experience. However, the yield is related to individual preparation time. Students overall find this to be a highly educational experience and highly recommend it be continued for future classes.

Although pair programming and software inspection have the common aim of minimizing the defects of the software product, each practice has its strengths and weaknesses. We need to understand their costs and benefits under given conditions to be able to select a practice to execute in a development project. The objective of this study is to compare the commonalities and differences between pair development and software inspection as verification techniques in Thailand. One classroom experiment and one industry experiment were conducted. The development effort and effect of quality were investigated with some additional calendar time comparisons. The classroom results showed that average development effort of the pair development group was 24% less than inspection group with the improved product quality. The industry experiment showed pair development to have about 4% more effort but about 40% fewer major defects. In addition, the impacts of cultural differences to the adoption of pair programming or software inspection in Thailand are discussed.

Software inspection has been shown to be an effective defect removal practice, leading to higher quality software with lower field failures. Automated software inspection tools are emerging for identifying a subset of defects in a less labor-intensive manner than manual inspection. This paper investigates the use of automated inspection for a large-scale industrial software system at Nortel Networks. We propose and utilize a defect classification scheme for enumerating the types of defects that can be identified by automated inspections. Additionally, we demonstrate that automated code inspection faults can be used as efficient predictors of field failures and are effective for identifying fault-prone modules.

A major goal of analytical quality assurance (QA) activities, e.g., inspection and testing, is detecting defects in software artifacts to increase product quality and decrease rework effort and cost. Inspection aims at identifying defects early and traditional testing focuses on test case generation and execution late in the development process. Combining inspection and test-case generation to inspection-based testing (UBT-i) can help identifying defects early, increasing testability by systematically capturing requirements and quality attributes, and generating most valuable test cases based on inspection results. This paper reports on a controlled experiment to investigate the temporal behavior of UBR inspection and inspection-based testing regarding defect detection performance, i.e., effectiveness, efficiency, and false positives. Main findings of the study are that there are no significant advantages of UBR and UBT-i regarding defect detection performance and the temporal behavior of defect detection delivered contradictory results in two sessions of the study.

The area of tool support for software inspection has been under active research since the early 1990’s. Although numerous implementations exist and development is still taking place, no tool has achieved a break-through. The main reason is that one tool usually demonstrates only one new idea, neglecting other features. A different approach must be taken, and software inspection tools should be seen as integral parts of the development environment. This paper categorises the existing tools into four generations based on the transition from traditional meeting support to asynchronous distributed inspections implemented with web technologies. Based on the analysis of 16 tools and our experiences, we summarize the most important features and add two new aspects to be notified when implementing the next generation of inspection tools for use in modern software development, flexibility and integration. The major focus is on comprehension, and we have taken the first steps at achieving this.

Process improvement activities in small and medium size enterprises (SME) are challenging due to small number of personnel and projects, people have to perform in a variety of roles. Assigning process improvement activities to the overburdened personnel may be seen as a threat to ongoing projects. Both management and staff should become convinced of the benefits of the improvement actions before taking the first step of the process. Even in this situation the software inspection provides a tempting starting point for process improvement. It is a focused and well defined subprocess and enables high return on investment benefits even in short period use. Our experiment in a small software company confirms that software inspection provides the justified starting point for process improvement. By means of the inspection maturity model the company recognises the weak points in their review practice and inspection patterns help in discovery of improvement actions.

Software inspection has been broadly accepted as a cost effective approach for defect removal during the whole software development lifecycle. To keep inspection under control, it is essential to measure its effectiveness. As human-oriented activity, inspection effectiveness is due to many uncertain factors that make such study a challenging task. Bayesian networks modeling is a powerful approach for the reasoning under uncertainty and it can describe inspection procedure well. With this framework, some extensions have been explored in this paper. The number of remaining defects in the software is proposed to be incorporated into the framework, with expectation to provide more information on the dynamic changing status of the software. In addition, a different approach is adopted to elicit the prior belief of related probability distributions for the network. Sensitivity analysis is developed with the model to locate the important factors to inspection effectiveness.

The motivation for this research comes from a need to improve software inspection practices in software organizations. Even if inspections are well defined and regularly used in an organization, there may be some problems which can greatly reduce inspection effectiveness. The paper presents a list of inspection related problems which are known in the literature. It also relates some experiences from two case organizations. In addition, this paper provides an approach which helps identifying problems of this kind and directing limited improvement resources effectively.

This is an experience report describing the results of a project to build and introduce an experimental CASE tool into a software engineering organization. The tool is Scrutiny, a CSCW system used to manage and facilitate the performance of software inspection and review by geographically separated teams. We describe Scrutiny and the lessons learned while building it and introducing it. The lessons learned are characterized as tool introduction, process, and user interface issues. >

The goal of software inspection is to identify defects and to measure the product and inspection process quality. Software development products that are suspected to contain a substantial number of defects after inspection may be subject to a second inspection cycle (re-inspection). So far, very few empirical results can be found on re-inspections. This paper reports on a controlled experiment that compares the effect of two inspection cycles. A software requirements document was re-inspected by 31 teams, after defects found during the initial inspection had been removed. We present data on the effectiveness, efficiency, net gain and return-on-investment from a second inspection cycle, and compare these results with data from the initial inspection. Models in the literature suggest decision criteria with regard to when to re-inspect, based on assumptions on the relationships of variables between the two inspection cycles. With experimental data, we evaluate these assumptions and the correctness of their decision criteria. The results of the experiment strongly support considering re-inspection as an option to improve product quality.

Software inspections have shown to contribute improved software quality. However, as they are time consuming; sometimes the resources available are not sufficient to inspect all documents. Instead of selecting documents ad hoc, sample-driven inspections (SDI) is proposed as a systematic approach to select which subset of documents to inspect. The selection is based on a pre-inspection, where samples of documents are inspected, and based on the sample, it is estimated which documents need the quality improvement the most. Two important questions are how select the pre-inspection sample, and how large segments the documents should be divided into. In this paper, we apply the SDI approach to industrial data from inspections of requirements specifications. Different sampling strategies are applied and the documents are split into segments of different size. It is concluded that the SDI approach is more effective in most cases compared to selecting subsets of documents randomly, despite the fact that the faults are rather evenly distributed in the documents.

Software inspections are commonly used throughout the software industry, but there are still open questions about the relationship between inspection processes and inspection effectiveness. For example, which techniques work best in various environments? Are requirements specifications inspections and code inspections different in terms of effectiveness? What is the effectiveness in inspections for different group sizes? Benchmarking provides an opportunity to address such issues. This paper discusses how benchmarking may be applied for software inspections. The discussion is illustrated with an empirical study. It is shown how the data can be used to plan and manage software inspections. It is concluded that software inspections are well suited for benchmarking and that software practitioners as well as researchers can learn valuable lessons.

Face-to-face meetings typically provide a natural way of negotiating and collecting opinions. The problem is that these meetings also cause resource problems, i.e. they waste time and are difficult to arrange. A shift to more flexible implementations of meetings is thus an understandable alternative. We could then remove barriers to the inclusion of inspections in the development process. The present paper outlines a solution to this problem and introduces a web generation of inspections, which utilises the collaborative aspects of the latest web technology, such as virtual (distributed) meetings and online recording. Web technology facilitates the collaborative aspects of inspection. This not only introduces flexibility into the inspection meetings, but also enables easy, manageable distribution of the artefacts for inspection, including the document to be inspected, checklists, or any other related documents. We introduce in particular the WiT (Web inspection Tool) tool, the main feature of which is the ability to inspect any HTML document.

Software inspection is an industry-proven process for improving quality and reducing cost and schedule risks during software development. Software inspections are highly effective at detecting and eliminating defects, especially during the early phases of software development. Unfortunately, the software inspection process is not widely used by DoD contractors. The Ballistic Missile Division Organization (BMDO) tasked IDA to promote awareness of this defect detection process to several BMD program offices. This report summarizes information collected, developed, and distributed to those program offices. IDA efforts to insert the process into BMDO policies, standards, and the Brilliant Eyes software development program are described.

The question of whether inspection meetings justify their cost has been discussed in several studies. However, it is still open as to how modern defect detection techniques and team size influence meeting performance, particularly with respect to different classes of defect severity. The influence of software inspection process parameters (defect detection technique, team size, meeting effort) on defect detection effectiveness is investigated, i.e. the number of defects found for 31 teams which inspected a requirements document, to shed light on the performance of inspection meetings. The sets of defects reported by each team after the individual preparation phase (nominal-team performance) and after the team meeting (real-team performance) are compared. The main findings are that nominal teams perform significantly more effectively than real teams for all defect classes. This implies that meeting losses are on average higher than meeting gains. Meeting effort was positively correlated with meeting gains, indicating that synergy effects can only be realised if enough time is available. With regard to meeting losses, existing reports are confirmed that for a given defect, the probability of being lost in a meeting decreases with an increase in the number of inspectors who detected this defect during individual preparation.

Software inspection processes call for a checklist to provide reviewers with hints and recommendations for finding defects during the examination of a workproduct. Many checklists have been published since Michael Fagan created the inspection process in the mid-1970's. This paper surveys 117 checklists from 24 sources. Different categories of checklist items are discussed and examples are provided of good checklist items as well as those that should be avoided.

In manufacturing, agriculture and transportation, inspections are a routine part of business, making our lives safer and more comfortable. Yet in software, we generally leave inspections to companies that are quite advanced in their process maturity. Why do most companies skip inspections when their is so much to gain? In 1991, the author began the National Software Quality Experiment, an ongoing database of software defects and inspections practice. In his study, participants from dozens of organizations described defects and these were entered into the experiment's database. In this article, the author makes a case for implementing inspections at all levels of software development practice, based on what he has learned thus far.

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.

The 12th Doctoral Symposium on Empirical Software Engineering (IDOESE), was organized as a full day event prior to the ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM) program. Seven PhD candidates came from different research institutes across the globe to present their research proposals at the symposium. The symposium was run in a lively and interactive manner. The candidates received constructive feedback on their proposals from all the symposium participants. In this report, we describe the presented proposals, focusing on the content and feedback.Through them, we can take a peek at the trends and emerging areas of empirical software engineering research. UCR::Vicerrectoría de Investigación::Unidades de Investigación::Ingeniería::Centro de Investigaciones en Tecnologías de Información y Comunicación (CITIC)

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.

Traditional Software Inspection is a well-established approach to identify defects in software artifacts and models early and efficiently. However, insufficient method and tool support hinder efficient defect detection in large software models. Recent Human Computation and Crowdsourcing processes may help to overcome this limitation by splitting complex inspection artifacts into smaller parts including a better control over defect detection tasks and increasing the scalability of inspection tasks. Therefore, we introduce a Crowdsourcing-Based Inspection (CSI) process with tool support with focus on inspection teams and the quality of defect detection. We evaluate the CSI process in a feasibility study involving 63 inspectors using the CSI process and 12 inspectors using a traditional best-practice inspection process. The CSI process was found useful by the participants. Although the preliminary results of the study were promising, the CSI process should be further investigated with typical large software engineering models.

Software inspection is widely acknowledged as an important method in software engineering. However, there is a need to better understand how to implement and improve inspection practices. This paper introduces Inspection Capability Maturity Model (ICMM), which provides support for assessment and improvement of software inspection practices in a software organization. The model has been developed iteratively based on a comprehensive literature survey and experiences from eight case organizations. This paper includes a detailed description of the used followed research process, the structure of ICMM and the rationale for the defined criteria. Additionally, the role of this kind of model in inspection process improvement is discussed. Copyright © 2010 John Wiley & Sons, Ltd.

According to Capability Maturity Model Integration (CMMI), the purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insights about processes and their associated work products. Such purpose is usually achieved through the implementation of software inspections. Although software inspection be a common practice, it is time-consuming and expensive, which turns the implementation in small and medium-sized teams infeasible. To improve the software inspection, this paper proposes a domain ontology for representing the concepts of quality assurance inspection, which is independent, extensive, shareable and semantically strong. Through the ontology it is possible to provide a formal structure to support the development of software engineering solutions with quality. To support the quality assurance inspections, we developed an agent-based prototype that encapsulates the ontology model. The prototype is able to generate inspection checklists and automatically allocate noncompliance issues. We validated the approach through a case study that shows an increase of inspection coverage and adherence of process.

This paper analyzes the effect on productivity by measuring Function Point per MM(man-month) in a software development project and code inspection which performed in Agile methodology, and introduce the method of applying MDA/MDD technology in the e-government standard framework project. MDA/MDD which recently raising its head is technology that increase software development productivity through automatic transformation form abstract model into lower abstract model, or from model to code. but, many Lessons obtained through the case studies, the analysis suggests a limited effect measurements. In this study, efficient development methodology and utilizing a e-government framework to measure the effectiveness of the MDD to the new measures through a case study applied to real information system development process. In addition to, managing information modeling through integrated repository presents a traceability and visibility.

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.

Specific features of software for computer aided inspection are detailed.Six commercial software packages are tested and compared through a fuzzy AHP analysis.GD&T functions and algorithms are not mature yet to provide consistent results.More expensive software with advanced features provide higher performances.The freeware Gom Inspect is a valid choice for basic inspection activities. Industrial metrology of mechanical components has been facing a gradual revolution recently through the application of contactless 3D scanners in computer aided inspection. Following the industrial trend and request, new modules for quality control activities on scan data have been integrated in reverse engineering software packages.The aim of this work is to propose a structured methodology for the screening and comparison of reverse engineering programs that are suitable for inspection activities. Specific features that distinguish this kind of software are described and detailed. Six different commercial software are tested using invariant scan data from a reference part that was specifically designed for inspection purposes.The selected packages are then compared by means of a multicriteria fuzzy AHP analysis that considers quantitative and qualitative criteria. The criteria were grouped into three categories related with the user, the vendor and the technical requirements. Two different scenarios are considered for the choice of the software that best suits to computer aided inspection activities.

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.

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 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.

After a software inspection the project manager has to decide whether he can pass a product on to the next software development stage or whether it still contains a substantial number of defects and should be reinspected to further improve its quality. While a substantial number of defects remaining in a product after inspection is a reasonable precondition to schedule a reinspection, it is also important to estimate whether the likely number of defects to be found with a reinspection will lower the defect density under the target threshold. In this work we propose a reliability growth model and two heuristic linear models for software inspection, which estimate the likely number of additional defects to be found during reinspection. We evaluate the accuracy of these models with time-stamped defect data from a large-scale controlled inspection experiment on reinspection. Main findings are: (a) The two best models estimated the defect detection capability for reinspection with good accuracy: over 80% of the estimates had an absolute relative error of under 10%; (b) The reinspection decision correctness based on the estimates of all investigated models, overall around 80% correct decisions, was much better than the trivial models to always or never reinspect; the latter is the default decision in practice.

Software inspection is well-known as an effective defect finding process. One avenue of inspection research concerns tool support, with the aim of further increasing its efficiency and effectiveness. This has resulted in the production of a number of prototype tools. In general, however, these tools are poorly evaluated and the performance gain which these tools may provide has not been quantified. This paper describes an incremental, cyclic approach to the development and evaluation of a tool to support software inspection. A version of the tool was developed then evaluated against traditional, paper-based inspection. The results were then used to guide development of the next version. This paper describes two of these cycles and the results of the corresponding evaluations. The approach was found to be a useful one, and is applicable to the development of many other tools, processes or procedures.

Visual inspection is a task regularly seen in manufacturing applications and is still primarily carried out by human operators. This study explored the use of job aids (anything used to assist the operator with the task, such as lists, check sheets or pictures) to assist with visual inspection within a manufacturing facility that inspects used parts. Job aids in the form of inspection manuals were used regularly during the inspection process, and how accurately they were followed was dependent on a number of factors such as size of part, experience of the operator, and accuracy of the inspection manuals. If the job aids were well structured, well written and accessible, then the inspectors were seen to follow them, however for certain jobs inspectors were seen to change the inspection order making inspection more efficient. The findings of the study suggest that prior experience can help in designing efficient, easy to use job aids and that a collaborative approach to design as well as using pictorial examples for comparison purposes would improve the inspection process.

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%.

Background: Definition of Done (DoD) is a Scrum practice that consists of a simple list of criteria that adds verifiable or demonstrable value to the product. It is one of the most popular agile practices and assures a balance between short-term delivery of features and long-term product quality, but little is known of its actual use in Agile teams.Objective: To identify possible gaps in the literature and define a starting point to define DoD for practitioners through the identification and synthesis of the DoD criteria used in agile projects as presented in the scientific literature.Method: We applied a Systematic Literature Review of studies published up to (and including) 2016 through database search and backward and forward snowballing.Results: In total, we evaluated 2326 papers, of which 8 included DoD criteria used in agile projects. We identified that some studies presented up to 4 levels of DoD, which include story, sprint, release or project. We identified 62 done criteria, which are related to software verification and validation, deploy, code inspection, test process quality, regulatory compliance, software architecture design, process management, configuration management and non-functional requirements.Conclusion: The main implication for research is a need for more and better empirical studies documenting and evaluating the use of the DoD in agile software development. For the industry, the review provides a map of how DoD is currently being used in the industry and can be used as a starting point to define or compare with their own DoD definition.

Inspection Capability Maturity Model (ICMM) is a new tool for the assessment and improvement of software inspection practices in an organization. This paper presents the first experiences in using ICMM. The model structure and usability is evaluated based on the data collected from eight case organizations. The major findings support the conclusion that ICMM worked well in identifying weaknesses in the current inspection practices. First, the perceived inspection quality in the organizations was compared with the assessment results. Second, the identified weaknesses appear to be related to the problems faced in inspection practices. Finally, the collected experiences provided some useful improvement suggestions for ICMM.