Contributions and Future Directions of Software Reviews

This chapter presents theoretical and methodological contributions. It also addresses the limitations of the empirical studies (i.e., industry survey and case study). Discussions of future research are presented in the final section of this chapter.

Industry Software Reviews Survey Design

Chapters five and six described the theoretical EIIO model; this chapter mainly focuses on industry survey design. The first section describes the research methodology and survey used to gather, collate, and analyse data for the study. After presenting the rationale for the research design, including the questionnaire design, measurement scales, and models. The chapter explores issues of validation and reliability, such as cross sectional research and construct operationalisation. The chapter concludes with a discussion of the data collection method and the analytical procedures used in the study.

Recommendations for Conducting Software Reviews

This chapter provides recommendations for conducting software reviews in software development environments. It is recommended that the software review process planning should consider three issues. These include: 1) decision on the selection of inputs, 2) a determination of the level of review meetings required, and 3) identifying the measurement metrics. For researchers, it is recommended that 1) future research should pay more attention to important relationships between software artefact characteristics and the use of supporting documents, 2) designing and conducting laboratory studies be done more realistically, 3) direct and indirect relationships between the use of inputs as predictors for software review performance, 4) the important relationships between the software artefact characteristics and meeting process factors, 5) meetings should be held when the artefact is complex, of large size and poor initial quality, 6) the use of previously reviewed software documents in relation to meeting process, 7) perceived contingency (motivation) is the most critical factor to meeting process, and 8) future studies should further concentrate on the use of previously reviewed software documents in combination with the implicit inputs, process, and performance.

A Revised EIIO Model and a Simple Software Review Guide

This chapter presents the revised EIIO model from the industry survey results. This includes analyzing the structure paths and validation of the final EIIO model. Use of inputs, meeting process, and review performance describes in the final section of the chapter. The chapter also proposes a simple guide for conducting software reviews, which includes: 1) identifying the characteristics of the software artefact, 2) decision of which supporting documents (reports and previously reviewed software documents) to use and reviewers’ experience required which are determined by software artefact characteristics, 3) selection of reviewers should be based on their role (review) experience and working experience in the software industry, and how they perceive company support and encouragement, and their acceptance levels of the company that is organising and conducting the software review; and 4) In the review meeting process, the most critical factor is teamwork which can be affected by the characteristics of the software artefact, use of previously reviewed software documents and reports, and perceived contingency (motivation).

How Software Review Tools Work

There are many software review tools for supporting the software review process, particularly in a group review. This chapter presents an overview of common software review tools and discussions on how these tools work in software review process. A number of software review tools will be discussed in this chapter. These include: Intelligent Code Inspection in a C Language Environment (ICICLE), Scrutiny, Collaborate Software Inspection (CSI), InspeQ, CSRS, Requirement Traceability tool (RADIX), InspectA, Asynchronous Inspection of Software Artefacts (AISA), Web Inspection Prototype (WiP), Asynchronous/Synchronous Software Inspection Support Tool (ASSIST), CORD, Agent-based Software Tool, Web-based Software Review System, Internet-Based Inspection System (IBIS) and VisionQuest.

Industry Software Reviews Survey Results and Findings

This chapter describes the industry survey results and findings, which include preliminary data analysis (missing value and descriptive data analyses), exploratory analyses (principal component analysis, and reliability and validity analysis) and hypotheses tests using Structural Equation Modeling Using Partial Least Squares (PLS) methodology. A total of 15 constructs with 48 indicators are used in the model, but only 15 paths are significant. The results of the model, using an inner model path weighting scheme show a substantial R-square of 0.398 for performance, a moderate level of 0.239 for experience and 0.335 for teamwork and a weak level of 0.024 for reports and 0.049 for previously reviewed software.

Software Review Tools and Technologies

This chapter presents software review tools and technologies which include: paper-based vs. tool-based software review, collaborative asynchronous vs. synchronous software reviews, applying software review tools in the software review process, paper-based and Web-based reviews tools, evaluation of asynchronous and synchronous design, and comparing software review tools features. This chapter also presents the software review tools can monitor and improve software review process, especially in a group review process. The final section of the chapter presents a knowledge centric software framework for building tools that perform software review, analysis, and transformations.

Software Review History and Overview

The aim of this chapter is to review software review literature. The literature is drawn from Fagan’s software review and forms of review structures. Fagan’s software review includes six-step review processes — planning, overview, preparation, group meeting, re-review, and follow up. The forms of review structures can be classified into Active Design Review, Two-Person Review, Phased Review, and Use of Review Meeting. The literature review also provides an understanding of the IEEE Standard for software reviews and informal software reviews. The common informal reviews include Walkthroughs, Pair Programming, Peer Check, and Pass-Around. It also compares and contrasts bring a comparison these review methods.

A Theoretical Model for Analysis of Software Review Performance

The aim of this chapter is to develop a theoretical model to assist in the analysis of critical inputs to software reviews and to identify process factors that might impact positively on software review performance. The Explicit, Implicit Input-process-Output (EIIO) model provides a sound theory to drive empirical research in software review and a different perspective to the existing literature that helps to facilitate understanding of the input-process-output relationship in software review process. An overall objective of the EIIO model is to identify what the key inputs are and process factor(s) that significantly influence review outcome(s). Five propositions, ten research questions, and 14 hypotheses are formulated to validate the important relationships between software inputs, processes, and performance.

Software Review, Inputs, Process, and Performance

The literature review in this chapter is aimed to critique the use of inputs and process support strategies in the software review process. This chapter presents the important relationships between the use of inputs, meeting process, and software review process performance. Inputs can be classified into explicit and implicit inputs. Explicit inputs refer to software review artefacts and supporting documents. Implicit inputs refer to a software reviewer’s characteristics. A meeting process refers factors that affect meeting process. The software review performance refers the outcomes from the meeting process. Software review performance can be measured by qualitative and/or quantitative methods. The final section presents the limitation of current software review literature.