Code Inspection Research Articles

A code inspection process for security reviews

In recent years, it has become more and more evident that software threat communities are taking an increasing interest in Grid infrastructures. To mitigate the security risk associated with the increased numbers of attacks, the Grid software development community needs to scale up effort to reduce software vulnerabilities. This can be achieved by introducing security review processes as a standard project management practice.The Grid Facilities Department of the Fermilab Computing Division has developed a code inspection process, tailored to reviewing security properties of software. The goal of the process is to identify technical risks associated with an application and their impact.This is achieved by focusing on the business needs of the application (what it does and protects), on understanding threats and exploit communities (what an exploiter gains), and on uncovering potential vulnerabilities (what defects can be exploited). The desired outcome of the process is an improvement of the quality of the software artifact and an enhanced understanding of possible mitigation strategies for residual risks.This paper describes the inspection process and lessons learned on applying it to Grid middleware.

Inferring design patterns using the ReP graph.

Periodic refactoring of a large source code often becomes a ne- cessity especially for long-lived projects. In order to increase maintainabil- ity and extensibility of such projects, design pattern based refactoring can be seen as an emerging alternative. Manual inspection of source code to find candidate spots where patterns can be introduced is time consuming. Therefore automated tools can help in identifying candidate spots where patterns can be introduced. The level of source code abstraction plays an important role for building such tools. We propose a new abstrac- tion for object oriented source code that is named as Refactoring Pattern (ReP) Graph to realize an eective design pattern based refactoring tool. The ReP graph abstracts the source code information thereby making the process of design pattern inference easier. The proposed tool identifies candidate spots in a given source code to introduce design patterns.

BUILDING MODEL DESIGN DEFECTS OBJECT ORIENTED SOFTWARE METHOD

In the paper the notion of object-oriented design defect progress degree is introduced and the method for defect models construction is proposed. Constructed models allow defect degree assessment. Reasons of design defect appearance and development are defined. State description of software element affected by design defect is ac-complished by design rules analysis, metrics normalizing and function building on the base of t-norm and t-conorm. God Class defect model is build and its adequacy is approved by manual code inspection.

Code inspection of welds using phased arrays

AbstractCritical welds need inspecting, because of either code requirements or structural integrity. Automated ultrasonics has proven more reliable than other techniques, such as radiography or manual techniques. Recently, portable phased arrays have become a dominant method of inspecting as they offer high speed, repeatable inspections. Techniques are available for a wide variety of vessels and pipes using commercial equipment. In addition, ASME section V now has five code cases available for phased array inspections of welds. One aspect of phased array inspections is that the coverage must be demonstrated using a scan plan, which can be a ray tracing programme showing the beam coverage, inspection angles, etc. This approach has big advantages for a flexible technology such as phased arrays; specifically, unusual weld profiles can be inspected using tailored scan plans. Unlike conventional ultrasonics or radiography, angles can be selected to optimise defect detection. Also, phased arrays can be adapted ...

Integrating pedagogical code reviews into a CS 1 course

Formal code inspections are employed by teams of professional software engineers to identify software defects and improve the quality of software. After reviewing a piece of code individually, members of an inspection team come together to log the issues they have found, and to find new ones. Within the scope of a multi-institutional research project to adapt, refine, and evaluate studio-based learning methods in computing education, we are developing an adaptation of the formal code inspection called the pedagogical code review for use in lower-division computer science courses. In a pedagogical code review, a group of three to four students, led by a trained moderator, (a) walk through segments of each other's programming assignments, (b) check the code against a list of best coding practices, and (c) discuss and log issues that arise. We implemented pedagogical code inspections in three lab sessions of a CS 1 course. Through an analysis of inspection logs and exit surveys, we compiled evidence that the reviews improved the quality of students' code, stimulated increasingly sophisticated discussions of programming issues and practices, and promoted a sense of community.

Theory of relative defect proneness

In this study, we investigated the functional form of the size-defect relationship for software modules through replicated studies conducted on ten open-source products. We consistently observed a power-law relationship where defect proneness increases at a slower rate compared to size. Therefore, smaller modules are proportionally more defect prone. We externally validated the application of our results for two commercial systems. Given limited and fixed resources for code inspections, there would be an impressive improvement in the cost-effectiveness, as much as 341% in one of the systems, if a smallest-first strategy were preferred over a largest-first one. The consistent results obtained in this study led us to state a theory of relative defect proneness (RDP): In large-scale software systems, smaller modules will be proportionally more defect-prone compared to larger ones. We suggest that practitioners consider our results and give higher priority to smaller modules in their focused quality assurance efforts.

Automating Software Testing Using Program Analysis

During the last 10 years, code inspection for standard programming errors has largely been automated with static code analysis. During the next 10 years, we expect to see similar progress in automating testing, and specifically test generation, thanks to advances in program analysis, efficient constraint solvers, and powerful computers. Three new tools from Microsoft combine techniques from static program analysis, dynamic analysis, model checking, and automated constraint solving while targeting different application domains.

Testing the Value of Checklists in Code Inspections

Checklists are an important part of code and design inspections. Ideally, they aim to increase the number of faults found per inspection hour by highlighting known areas of previous failure. In practice, although some researchers have quantified checklists' benefits, the conclusions' statistical robustness hasn't been as well represented. The author subjects checklists' effectiveness to formal statistical testing, using data from 308 inspections by industrial engineers over a three-year period. The results showed no evidence that checklists significantly improved these inspections. Further analysis revealed that individual inspection performance varied by a factor of 10 in terms of faults found per unit time, and individuals found on average about 53 percent of the faults. Two-person teams found on average 76 percent of the faults.

Inspection and Verification of Medical Drug Bar Code (GS1-RSS)

Inspection and Verification of Medical Drug Bar Code (GS1-RSS)

Trusting Computers Through Trusting Humans

This article considers the question of how we may trust automatically generated program code. The code walkthroughs and inspections of software engineering mimic the ways that mathematicians go about assuring themselves that a mathematical proof is true. Mathematicians have difficulty accepting a computer generated proof because they cannot go through the social processes of trusting its construction. Similarly, those involved in accepting a proof of a computer system or computer generated code cannot go through their traditional processes of trust. The process of software verification is bound up in software quality assurance procedures, which are themselves subject to commercial pressures. Quality standards, including military standards, have procedures for human trust designed into them. An action research case study of an avionics system within a military aircraft company illustrates these points, where the software quality assurance (SQA) procedures were incommensurable with the use of automatically generated code.

Maximising the information gained from a study of static analysis technologies for concurrent software

The results of empirical studies in Software Engineering are limited to particular contexts, difficult to generalise and the studies themselves are expensive to perform. Despite these problems, empirical studies can be made effective and they are important to both researchers and practitioners. The key to their effectiveness lies in the maximisation of the information that can be gained by examining and replicating existing studies and using power analyses for an accurate minimum sample size. This approach was applied in a controlled experiment examining the combination of automated static analysis tools and code inspection in the context of the verification and validation (V&V) of concurrent Java components. The paper presents the results of this controlled experiment and shows that the combination of automated static analysis and code inspection is cost-effective. Throughout the experiment a strategy to maximise the information gained from the experiment was used. As a result, despite the size of the study, conclusive results were obtained, contributing to the research on V&V technology evaluation.

Safety of Application Programming for Railway Signal Controllers

A model that provides a framework for assessing verification and validation techniques for application programming for the safety of railway signaling systems is presented. A railway signaling system is a logical controller, also known as interlocking, that ensures that conflicting train movements are not signaled. The signal interlockings, as a data-driven systems sets out a logical relationship and instructions which comprise the procedures by which the interlocking implements the required signaling functions. The safety assurance is assessed by Intensity Capability of the inspection system, effect of application parameters, and the effect of human and environmental factors. The code inspection analyzes program behavior by producing programs from interpretation of codes and checks the applicability of codes in the event of fatigue or loss of concentration, to evaluate errors in complex railway processes.

Improving Software Development through Three Stages

In three stages covering 12 years and 16 projects, a software development group worked on attaining visible schedule control and usable software design documentation. The first stage identified two major problems: unstable code and schedule delays. The group used code inspection to address the immediate issue of code construction. In the second stage, the group formulated and implemented a software development process that addressed the entire software development life cycle. The third stage improved that process. The major factor in process improvement was the group's willingness to identify its mistakes and problems.

Distributed desk checking

AbstractDesk checking is known to be an effective reading technique for early detection of sequential program errors. This paper discusses how to extend desk checking for concurrent and distributed programs. In addition to exponential possible schedules, concurrent and distributed programs have execution states that include more than one process. The new distributed desk‐checking technique supports the selection of schedules and execution states to be reviewed. The cross‐product functional coverage technique assists in the selection process. Schedule selection guidelines that facilitate early detection and coverage are introduced. It is demonstrated that code inspection can be applied effectively to large industrial applications using the selection mechanism introduced by this technique. Industrial pilots show that distributed desk checking is an effective early error‐detection review technique. Copyright © 2006 John Wiley & Sons, Ltd.

A COLLABORATIVE SOFTWARE CODE INSPECTION: THE DESIGN AND EVALUATION OF A REPEATABLE COLLABORATION PROCESS IN THE FIELD

The use of software products in today's world has increased dramatically making quality an important aspect of software development. There is a continuous need to develop processes to control and increase software quality. Software code inspection is one way to pursue this goal. This paper presents a collaborative code inspection process that was designed during an action research study using Collaboration Engineering principles and techniques. Our inspection process was implemented as a sequence of thinkLets, chunks of facilitation skill, that were subsequently field tested in a traditional paper-based and Group Support System (GSS)-based environment. Four inspections were performed on four different pieces of software code in two different organizations. Results show that regardless of the implementation, the process was found to be successful in uncovering many major, minor, and false-positive defects in inspected pieces of code. Overall observations and feedback suggest that the collaborative inspection process was considered to be productive and satisfactory. GSS inspections were more effective, especially in terms of major defects. GSS inspections were also found to be more efficient. Finally, the GSS inspections outperformed the paper inspections from a practical perspective: logging and managing defects in a GSS was far superior.

Students working for students on programming courses

In this paper we offer a report on a university-level programming laboratory course that has been designed on top of a programming library. The course enforces soft skills, such as code inspection and team working, sharpens implementation skills and creates a bridge between introductory, language-specific instruction and senior-year full-blown programming projects that are usually large but not attending to soft skills. Quite as importantly, it has also delivered a working research tool.

Software validation in metrology: A case study for a GUM-supporting software

Software validation in metrology is a crucial, often highly interdisciplinary process. One needs to consider all steps beginning with the definition of requirements and ending with the provision of evidence that the requirements are fulfilled. This includes the refinement of requirements to testable attributes, the selection of appropriate validation methods, the proper execution of methods and the documentation of results. As regards the validation methods, functional tests of measuring devices are preferred in metrology, although this is not always justified. Dynamic tests of the executable software code as well as code inspections may be very beneficial and often more straightforward than expected. An extended approach of validation in metrology that includes a rigorous refinement of requirements, dynamic software tests and code inspections is demonstrated by a case study. The target of validation is a software that claims to be conform to the Guide to the Expression of Uncertainty in Measurement (GUM). The contributions of various validation methods to confirm the fulfilment of requirements related to GUM and the benefits of this approach are shown.

Trustworthy systems through quantitative software engineering

Trustworthy systems through quantitative software engineering

Foundations and applications for secure triggers

Imagine there is certain content we want to maintain private until some particular event occurs, when we want to have it automatically disclosed. Suppose, furthermore, that we want this done in a (possibly) malicious host. Say the confidential content is a piece of code belonging to a computer program that should remain ciphered and then “be triggered” (i.e., deciphered and executed) when the underlying system satisfies a preselected condition, which must remain secret after code inspection. In this work we present different solutions for problems of this sort, using different “declassification” criteria, based on a primitive we call secure triggers . We establish the notion of secure triggers in the universally composable security framework of Canetti [2001] and introduce several examples. Our examples demonstrate that a new sort of obfuscation is possible. Finally, we motivate its use with applications in realistic scenarios.

Simulant Melt Experiments on Thermal and Metallurgical Performance of the In-Vessel Core Catcher

LAVA-GAP experiments were performed to investigate the thermal and mechanical performance of the in-vessel core catcher, which was proposed to improve in-vessel retention for high-power reactors. In the LAVA-GAP experiments, alumina melt was used as a core material simulant. The hemispherical in-vessel core catcher made of carbon steel was installed inside the lower head vessel maintaining a uniform gap of 10 mm from the inner surface of the lower head vessel. Two types of in-vessel core catchers were used in this study. The first one is a single-layered in-vessel core catcher without an internal coating, and the other one is a two-layered in-vessel core catcher with a 0.5-mm-thick ZrO2 internal coating. LAVA-GAP experimental results indicate that an internally coated in-vessel core catcher has better thermal performance compared with an uncoated in-vessel core catcher. For the precise investigations on the thermal and mechanical response of the in-vessel core catcher, thermal analyses using the LiLAC code and metallurgical inspections were performed. LiLAC calculation results suggest that the coating layer could lessen the thermal attack transferred to the core catcher and result in improving the integrity of the core catcher in the LAVA-GAP experiments. Metallurgical inspection results indicate that the carbon steel showed stable and pure chemical compositions without any oxidation and interaction with the coating layer. In terms of the material aspects, these metallurgical inspection results suggest that the ZrO2 coating performed well.