Can using Fagan Inspections improve the quality of specification in 2011? A Case Study

In this paper, we explore why Fagan Inspections have become obsolete in the software industry, given the body of evidence which supports their use to improve the quality of software artefacts and the software development process. Since the late 1970’s, much has been written about how Fagan Inspections improve the quality of both processes and outputs of the software development process. The literature indicates that the Fagan Inspection technique can improve quality of software (or other software development artefacts) by a reduction in defects of 60 – 90%. However, recent literature suggests that inspection techniques in general and Fagan Inspections in particular, are no longer used. A study in 1998 found that respondents used inspections either irregularly or not at all. Teams often review artefacts informally, but believe that they are performing an inspection or formal review. The lack of rigour in the review process results in reduced benefits and more defects in the artefacts. To explore this situation, we conducted a case study with a local enterprise and we report on the early findings. These suggest that the introduction of Fagan Inspections may have a number of benefits before they have even been introduced fully, including recognition of flaws in the current development process, development of technical knowledge relating to the software process domain, and improved team relations and a ‘quality’ culture. In addition, the personnel using Fagan Inspection gain experience in the production of ‘quality’ artefacts

A Review of Software Inspections

For two decades, software inspections have proven effective for detecting defects in software. We have reviewed the different ways software inspections are done, created a taxonomy of inspection methods, and examined claims about the cost-effectiveness of different methods. We detect a disturbing pattern in the evaluation of inspection methods. Although there is universal agreement on the effectiveness of software inspection, their economics are uncertain. Our examination of several empirical studies leads us to conclude that the benefits of inspections are often overstated and the costs (especially for large software developments) are understated. Furthermore, some of the most influential studies establishing these costs and benefits are 20 years old now, which leads us to question their relevance to today's software development processes. Extensive work is needed to determine exactly how, why, and when software inspections work, and whether some defect detection techniques might be more cost-effective than others. In this article we ask some questions about measuring effectiveness of software inspections and determining how much they really cost when their effect on the rest of the development process is considered. Finding answers to these questions will enable us to improve the efficiency of software development. (Also cross-referenced as UMIACS-TR-95-104

Evaluating the utility of multi-user VR in product development

Verifying the design of a mechanical product typically requires a physical mockup. Virtual reality can avoid this by letting workers experience real-size design inspections avoiding to waste time and money to produce physical and potentially still faulty assets. Multi-user environments have been studied to verify the utility of virtual reality in performing design reviews for maintainability. The main features required in such software have been determined. A systematic literature review on the state of the art usages of virtual reality for design inspections and industrial training completes the thesis

Tools, processes and factors influencing of code review

Code review is the most effective quality assurance strategy in software development where reviewers aim to identify defects and improve the quality of source code of both commercial and open-source software. Ultimately, the main purpose of code review activities is to produce better software products. Review comments are the building blocks of code review. There are many approaches to conduct reviews and analysis source code such as pair programming, informal inspections, and formal inspections. Reviewers are responsible for providing comments and suggestions to improve the quality of the proposed source code modifications. This work aims to succinctly describe code review process, giving a framework of the tools and factors influencing code review to aid reviewers and authors in the code review stages and choose the suitable code review tool

Software Engineering Research/Developer Collaborations (C104)

The goal of this collaboration was to produce Flight Software Branch (FSB) process standards for software inspections which could be used across three new missions within the FSB. The standard was developed by Dr. Forrest Shull (Fraunhofer Center for Experimental Software Engineering, Maryland) using the Perspective-Based Inspection approach, (PBI research has been funded by SARP) , then tested on a pilot Branch project. Because the short time scale of the collaboration ruled out a quantitative evaluation, it would be decided whether the standard was suitable for roll-out to other Branch projects based on a qualitative measure: whether the standard received high ratings from Branch personnel as to usability and overall satisfaction. The project used for piloting the Perspective-Based Inspection approach was a multi-mission framework designed for reuse. This was a good choice because key representatives from the three new missions would be involved in the inspections. The perspective-based approach was applied to produce inspection procedures tailored for the specific quality needs of the branch. The technical information to do so was largely drawn through a series of interviews with Branch personnel. The framework team used the procedures to review requirements. The inspections were useful for indicating that a restructuring of the requirements document was needed, which led to changes in the development project plan. The standard was sent out to other Branch personnel for review. Branch personnel were very positive. However, important changes were identified because the perspective of Attitude Control System (ACS) developers had not been adequately represented, a result of the specific personnel interviewed. The net result is that with some further work to incorporate the ACS perspective, and in synchrony with the roll out of independent Branch standards, the PBI approach will be implemented in the FSB. Also, the project intends to continue its collaboration with the technology provider (Dr. Forrest Shull) past the end of the grant, to allow a more rigorous quantitative evaluation

Individual Code Reviews to Improve Solo Programming

Programming is a difficult subject for many students and therefore a popular topic in computing education research, with extensive research into the teaching and learning of programming (Sheard et al., 2009).Peer code reviews (or code inspections,) have been successfully applied to the teaching of programming (Hundhausen et al., 2009, Trytten, 2005, Wang et al., 2008). Code reviews can also be applied in a individual context as in the Personal Software Process (PSP) (Humphrey, 1997). Making the review process individual eliminates the problems associated with group and pair work as the student is working alone. The aim of this research is to ascertain whether individual code reviews based on checklists (like those used in PSP (Humphrey, 1997) and during formal code inspections in industry (Sommerville, 2007),) with minimal reporting can be used to improve solo programming.The results shown an increase in performance however this is not statistically significant possibly due to the small sample size