For two decades, software inspections have proven e ective for detecting defects in software. We have reviewed the di erent ways software inspections are done, created a taxonomy of inspection methods, and examined claims about the cost-e ectiveness of di erent methods. We detect a disturbing pattern in the evaluation of inspection methods. Although there is universal agreement on the e ectiveness of software inspection, their economics are uncertain. Our examination of several empirical studies leads us to conclude that the bene ts of inspections are often overstated and the costs (especially for large software developments) are understated. Furthermore, some of the most in uential studies establishing these costs and bene ts 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-e ective than others. In this article we ask some questions about measuring e ectiveness of software inspections and determining how much they really cost when their e ect on the rest of the development process is considered. Finding answers to these questions will enable us to improve the e ciency of software development. 1

There are four fundamental aspects of use and reuse in building systems from components: conceptualization, retrieval, selection and correct use. The most important barrier to use and reuse, initially at least, is that of conceptualization. The Inscape Environment is a specification-based software development environment (SDE) integrated by the constructive use of formal interface specifications. The purpose of the formal interface specifications and the semantic interconnections (created and maintained as software is built and evolved) is to make explicit the invisible semantic dependencies that result in conventionally built systems. The important ingredient provided by Inquire in conceptualization, retrieval, selection and use is the set of predicates that describe the semantics of the elements in the interface. These predicates define the abstractions that are germane to the module interface and describe the properties of data objects and the assumptions and results of operations i...

Software inspections have long been considered to be an effective way to detect and remove defects from software. However, there are costs associated with carrying out inspections and these costs may outweigh the expected benefits. It is important to understand the tradeoffs between these costs and bene ts. We believe that these are driven by several mechanisms, both internal and external to the inspection process. Internal factors are associated with the manner in which the steps of the inspection are organized into a process (structure), as well as the manner in which each step is carried out (technique). External ones include differences in reviewer ability and code quality (inputs), and interactions with other inspections, the project schedule, personal calendars, etc. (environment). We started a study to identify the mechanisms that strongly in uence an inspection's costs and effectiveness. Most of the existing literature on inspections have discussed how to get the most benefit out of inspections by proposing changes to the process structure, but with little or no empirical work conducted

Although meant to be relatively stable, the architecture of a software system does, at times, change. This simple yet important observation immediately raises the question of how changes to an architecture should be captured. Current architecture description languages are not well-suited for this purpose, but existing techniques from the discipline of configuration management can be adapted to provide a solution. In particular, we propose a novel representation, called configurable software architecture, that extends the traditional notion of software architecture with the concepts of variants, options, and evolution. We discuss the details of the representation, present an environment that allows the specification of configurable software architectures, and highlight a few of the opportunities that we believe arise once architectural configurability can be precisely captured.

Evolving a large system presents a number of signi cant challenges. Not only is the developer concerned about how to t in a new feature to a maze of existing features, he has to make surehischanges do not con ict with those being made in parallel by his colleagues. This is a minor problem in small projects with small organizations. However, as the project size scales up, so does the organization, and management of parallel tracks of development becomes a major concern. Moreover, increasing usage by customers with diverse needs pulls the evolving software into di erent directions, necessitating the evolution of multiple customized versions and compounding the already complex problem of evolving legacy systems. We will examine one such legacy system, the Lucent Technologies 5ESS R switching system. First introduced in 1982, 5ESS was envisioned to support telecommunication needs well into the next century. Already one of the largest and most complex pieces of real time code in the world, the software to run the switch still continues to evolve with new features and in an increasing number of customized versions. In order to keep up with future evolution and maintain the growing base of customers, a combined procedural and technological solution was put in place. We will discuss this particular solution and its limitations. 1

Regression testing is an important but expensive activity, and a great deal of research on regression testing methodologies has been performed. In recent years, much of this research has emphasized empirical studies, including evaluations of the effectiveness and efficiency of regression testing techniques. To date, however, most studies have been limited in terms of their consideration of testing context and system lifecycle, and have used cost-benefit models that omit important factors and render some types of comparisons between techniques impossible. These limitations can cause studies to improperly assess the costs and benefits of regression testing techniques in practical settings. In this paper, we provide improved cost-benefit models for use in assessing regression testing methodologies, that incorporate context and lifecycle factors not considered in prior studies, and we use these models to compare several common methodologies. Our results show that the factors we consider (in particular, time constraints and incremental resource availability) can affect assessments of the relative benefits of regression testing techniques, and suggest that particular classes of techniques may compare differently across different types of test suites.

A novel approach to modeling the software development process is presented. This approach is based on the use of concepts and techniques from the theory of state variables and feedback control. The reasons to use this approach and its advantages are presented. A model for the Software Test Process is developed to show the approach applicability to the software development process. The assumptions and choice of parameters used in the model are discussed.

Architecture and design intent are critical elements in the development and evolution of software systems. They are critical in two ways. First, there must be a shared understanding of them to adequately and effectively build and evolve our systems. Second, this shared understanding is needed to coordinate the various developers and teams of developers, especially in evolving our systems. The lack of access to internal implementation details makes the issue of architecture and design intent even more critical in COTS and component based systems. We explore the issues involved in supporting the reification and use of architecture and design intent, discuss a selection of approaches, and present some ideas we have about its use in both planned and agile contexts. 1.

Abstract not found

I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as ac-cepted by my examiners. I understand that my thesis may be made electronically available to the public. ii During software development and maintenance, as a software system evolves, changes are made and bugs are fixed in various files. In large-scale systems, file histories are stored in software repositories, such as CVS, which record modifica-tions. By studying software repositories, we can learn about open source software development processes. Knowing where these changes will happen in advance, gives power to managers and developers to concentrate on those files. Due to the unpredictability in software development process, proposing an accurate change prediction model is hard. It is even harder to compare different models with the actual model of changes that is not available.