This paper contributes an integrated survey of the work in the area of software inspection. It consists of two main sections. The first introduces a detailed description of the core concepts and relationships that together define the field of software inspection. The second elaborates a taxonomy that uses a generic development life-cycle to contextualize software inspection in detail. After Fagan's seminal work presented in 1976, the body of work in software inspection has greatly increased and reached measured maturity. Yet, there is still no encompassing and systematic view of this research body driven from a life-cycle perspective. This perspective is important since inspection methods and refinements are most often aligned to particular life-cycle artifacts. It also provides practitioners with a road-map available in their terms. To provide a systematic and encompassing view of the research and practice body in software inspection, the contribution of this survey is, in a first s...

Software engineering focuses on producing quality software products through quality processes. The attention to processes dates back to the early 70's, when software engineers realized that the desired qualities (such as reliability, efficiency, evolvability, ease of use, etc.) could only be injected in the products by following a disciplined flow of activities. Such a discipline would also make the production process more predictable and economical.

Most modern business activities are carried out by a combination of computerized tools and human agents. Typical examples are engineering design activities, office procedures, and banking systems. All these human-centered systems are characterized by the interaction among people, and between people and computerized tools. This interaction defines a process, whose effectiveness is essential to ensure the quality of the delivered products and/or services. To support these systems, process-centered environments and workflow management systems have been recently developed. They can be collectively identified with the term process technology. This technology is based on the explicit definition of the process to be followed (the process model ). The model specifies the kind of support that has to be provided to human agents. An essential property that process technology must exhibit is the ability of tolerating, controlling, and supporting deviations and inconsistencies of the real...

We replicated a controlled experiment first run in the early 1980's to evaluate the effectiveness and efficiency of 50 student subjects who used three defect-detection techniques to observe failures and isolate faults in small C programs. The three techniques were code reading by stepwise abstraction, functional (black-box) testing, and structural (white-box) testing. Two internal replications showed that our relatively inexperienced subjects were similarly effective at observing failures and isolating faults with all three techniques. However, our subjects were most efficient at both tasks when they used functional testing. Some significant differences among the techniques in their effectiveness at isolating faults of different types were seen. These results suggest that inexperienced subjects can apply a formal verification technique (code reading) as effectively as an execution-based validation technique, but they are most efficient when using functional testing.

Test-driven development is a software development practice that has been used sporadically for decades. With this practice, test cases (preferably automated) are incrementally written before production code is implemented. Test-driven development has recently reemerged as a critical enabling practice of the Extreme Programming software development methodology. We ran a case study of this practice at IBM. In the process, a thorough suite of automated test cases was produced. In this case study, we found that the code developed using a test-driven development practice showed, during functional verification and regression tests, approximately 40 % fewer defects than a baseline prior product developed in a more traditional fashion. The productivity of the team was not impacted by the additional focus on producing automated test cases. This test suite will aid in future enhancements and maintenance of this code. The experiment and the results are discussed in detail. 1.

Techniques for detecting defects in source code are fundamental to the success of any software development approach. A software development organization therefore needs to understand the utility of techniques such as reading or testing in its own environment. Controlled experiments have proven to be an effective means for evaluating software engineering techniques and gaining the necessary understanding about their utility. This paper presents a characterization scheme for controlled experiments that evaluate defect-detection techniques. The characterization scheme permits the comparison of results from similar experiments and establishes a context for crossexperiment analysis of those results. The characterization scheme is used to structure a detailed survey of four experiments that compared reading and testing techniques for detecting defects in source code. We encourage educators, researchers, and practition- Also with the Department of Computer Science, University of Kaiserslaut...

Pair programming is a kind of collaborative programming where two people are working simultaneously on the same programming task. It is one of the key practices of eXtreme Programming. In the paper we compare it with two variants of individual programming: one of them is based on Personal Software Process that has been proposed by W. Humphrey, and the other is a variant of eXtreme Programming tailored to individuals. Four experiments are described that has been performed at the Poznan University of Technology. During those experiments 21 students wrote 4 C/C++ programs ranging from 150 to 400 LOC. The obtained results are compared with the results of similar experiments described by J.T. Nosek and L. Williams et al.

By the early 1990s the need for reengineering legacy systems was already acute, but recently the demand has increased significantly with the shift toward web-based user interfaces. The demand by all business sectors to adapt their information systems to the Web has created a tremendous need for methods, tools, and infrastructures to evolve and exploit existing applications efficiently and cost-effectively. Reverse engineering has been heralded as one of the most promising technologies to combat this legacy systems problem. This paper

An experiment was conducted to compare programmer productivity and defect rates for Java and C++. A modified version of the Personal Software Process (PSP) was used to gather defect rate, bug rate, and productivity data on C++ and Java during two real world development projects. A bug is defined to be a problem detected during testing or deployment. A defect is either a bug, or an error detected during compile time. A typical C++ program had two to three times as many bugs per line of code as a typical Java program. C++ also generated between 15 per cent and 50 per cent more defects per line, and perhaps took six times as long to debug. Java was between 30 per cent and 200 per cent more productive, in terms of lines of code per minute. When defects were measured against development time, Java and C++ showed no difference, but C++ had two to three times as many bugs per hour. Statistics were generated using Student’s t-test at a 95 per cent confidence level. Some discussion of why the differences occurred is included, but the reasons offered have not been tested experimentally. The study is limited to one programmer over two projects, so it is not a definitive experimental result. The programmer was experienced in C++, but only learning Java, so the results would probably favour Java more strongly for equally-experienced programmers. The experiment shows that it is possible to experimentally measure the fitness of a programming language.

“Knowledge is commonly socially constructed, through collaborative efforts toward shared objectives or by dialogues and challenges brought about by differences in persons ' perspectives. " [1] Industry, particularly those following the eXtreme Programming (XP) methodology [2], has popularized the use of pair-programming. The pair-programming model has also been found to be beneficial for student programmers. Initial quantitative and qualitative results, which will be discussed in this paper, demonstrate that the use of pair-programming in the computer science classroom enhances student learning and satisfaction and reduces the frustration common among students. Additionally, the use of pair-programming relieves the burden on the educators because students no longer view the teaching staff as their sole form of technical information. We explore the nature of pair-programming, then examine the ways such a practice may enhance teaching and learning in computer science education. 1