Software Inspection is an effective and efficient method aiming at discovering faults within software artifacts early in the development lifecycle. The success of software inspections is highly dependent on reading techniques that guide the reviewer through the individual inspection. In other words, reading techniques help the reviewer during the inspection process. In this thesis a quite new reading technique, namely usage-based reading, is further evaluated. A reviewer who applies usage-based reading is guided by a set of prioritized use-cases. Hereby the use-cases are ranked according to their importance from the point of view of the user. Thus, the reviewers inspection effort is focused on the parts of the document that concern the most important functionality from the user’s perspective. The particular goal of this study is to figure out whether time-budgets assigned to each use-cases lead to improvements in inspection performance expressed in terms of efficiency, effectiveness and fault content. This concept is called time-controlled reading. The time-budget determines that a particular use-case must not be inspected longer than a certain number of minutes. Initially the assumption was made that time-budgets lead to performance improvements because the reading process can be better planned in forehand, that means most time is spent on the most important use-cases and all use-cases are utilized within the given inspection time. However, the result of this study contradicts that assumption. I found that both techniques are equally efficient and effective and that they find the same fault content. The reason for this is that the techniques are still quite similar and that the timebudgets assigned to the use-cases did not allow the subjects to thoroughly investigate the use-cases because they struggled with the unknown application domain. This is at least the case for lower ranked use-cases with smaller time-frames. As a consequence of this, one can claim that the results might have pointed in favor for time-controlled reading when people familiar with the application domain would have done the same experiment. / kai-petersen@gmx.de

Aspect-Oriented Software Development (AOSD) is a new approach that addresses limitations inherent in conventional programming, especially the principle of separation of concerns by emphasizing the encapsulation and modularization of crosscutting concerns through a new abstraction, the "aspect." Aspect-oriented programming is an emerging AOSD programming paradigm that focuses on the modularization of concerns as appropriate for the host language and providing a mechanism for describing concerns that crosscut each other by congealing into a single textual structure behavior that conventional programming would otherwise distribute throughout the code. AspectJ is the most widely used aspect-oriented programming language to date and provides an extension of the Java language that includes several new concepts and constructs that differ from those in procedural and object-oriented programs. These include join points, pointcuts, advice, inter-type declarations, introduction and aspects. In AspectJ, as well as other aspect-oriented programming languages, "aspects" package pointcuts and advice into functional units in much the same way that object-oriented programming uses classes to package fields and methods into cohesive units but they offer a unique set of problems. Software inspections are considered a software engineering "best practice" for ensuring quality, but the introduction of new aspect-oriented programming language mechanisms drives the need for them to be tailored in a similar manner to how they were tailored to support object-oriented programs and the procedural programs. The identification of faults unique to aspect-oriented programming allowed for the design of an aspect fault model and the associated software inspection checklists criteria that provide a description of the typical faults associated with aspects and the clues that aid in betraying their presence. The proposed methodology for this research entailed a mixed methods approach based on a combination of descriptive and exploratory research methodologies using a normative case study. The proposed methodology resulted in the development of an understanding of the AspectJ primitive pointcut construct, identification of the typical faults associated with this construct and the subsequent development of a fault model, a set of programming rules and tailored software inspection checklist. A case study was conducted comparing defects detected by an inspection checklist tailored for AspectJ with one that was not tailored. The results of the case study demonstrated using software inspection checklists not tailored would result in many faults unique to aspect-oriented programming going undetected.