Abstract- Embedded assertions have been recognized as a potentially powerful tool for automatic runtime detection of software faults during debugging, testing, maintenance and even production versions of software systems. Yet despite the richness of the notations and the maturity of the techniques and tools that have been developed for programming with assertions, assertions are a development tool that has seen little widespread use in practice. The main reasons seem to be that (1) previous assertion processing tools did not integrate easily with existing program-ming environments, and (2) it is not well understood what kinds of assertions are most effective at detecting software faults. This paper describes experience using an assertion processing tool that was built to address the concerns of ease-of-use and effective-ness. The tool is called APP, an Annotation PreProcessor for C programs developed in UNIX-based development environments. APP has been used in the development of a variety of software systems over the past five years. Based on this experience, the paper presents a classification of the assertions that were most effective at detecting faults. While the assertions that are described guard against many common kinds of faults and errors, the very commonness of such faults demonstrates the need for an explicit, high-level, automatically checkable specification of required behavior. It is hoped that the classification presented in this paper will prove to be a useful first step in developing a method of programming with assertions. Index Terms-Anna, APP, assertions, C, consistency checking, formal specifications, formal methods, programming environ-

The Inscape Environment is an integrated software development enviroment for building large software systems by large groups of developers. It provides tools that are knowledgeable about the process of system construction and evolution and that work in symbiosis with the system builders and evolvers. These tools are integrated around the constructive use of formal module interface specifications. We first discuss the problems that Inscape addresses, outline our research strategies and approaches to solving these problems, and summarize the contributions of the Inscape Environment. We then discuss the major aspects

The standard software development process consists of multiple stages: requirements, design, coding, system test, first office, and finally delivery. An objective of this process is to minimize the number of faults in delivered code. Root cause analysis shows that many of the faults can be traced back to requirements or design faults. As part of the software development process, reviews are conducted to remove these faults before the requirements or design document is passed on to the next step. We have developed a method of instrumenting a review process to record document faults discovered by reviewers during their preparation. Then, using statistical techniques related to capture-recapture methods, we estimate the number of undiscovered faults remaining in the document. The key idea to our method is to look at how many common faults independent reviewers find and then extrapolate to the total number of faults. We do not seed the document with artificial faults - no additional faults...

Understanding the impact of software changes has been a challenge since software systems were first developed. With the increasing size and complexity of systems, this problem has become more difficult. There are many ways to identify the impact of changes on the system from the plethora of software artifacts produced during development and maintenance. We present the analysis of the software development process using change and defect history data. Specifically, we address the problem of small changes. The studies revealed that (1) there is less than 4 percent probability that a one-line change will introduce an error in the code; (2) nearly 10 percent of all changes made during the maintenance of the software under consideration were one-line changes; (3 the phenomena of change differs for additions, deletions and modifications as well as for the number of lines affected. 1.

. We report the results of a survey about the software faults encountered during the testing phases in evolving a large real-time system. The survey was done in two parts: the first part surveyed all the faults that were reported and characterized them in terms of general categories; the second part resurveyed in depth the faults found in the design and coding phases. For the first part, we describe describe the questionaire, report the general faults found, and characterize the requirements, design and coding faults by the testing phases in which they were found and by the time they were found during the testing interval. For the second part, we describe the questionaire used to survey the design and coding faults, report the faults that occurred, how difficult they were to find and fix, what their underlying causes were (that is, what their corresponding errors were), and what means might have prevented them from occurring. We then characterize the results in terms of interface and i...

We introduce and compare two models of cooperation among programmers during software maintenance. Enforced cooperation is the normal mode of operation when the sheer size of the software maintenance effort makes laissez-faire management infeasible. Voluntary cooperation is more common when a small group works together to enhance a small system or modify a small portion of a large system. We describe a tool, Infuse, that provides change management in the context of both models of cooperation. We demonstrate how Infuse automates change propagation and enforces negotiation of conflicts for the enforced model, but provides less restrictive aids for maintaining consistency for the voluntary model. _______________ * Supported in part by a grant from the AT&T Foundation, in part by a grant from Siemens Research and Technology Laboratories, and in part by a Faculty Award from Digital Equipment Corporation. 1. Introduction The maintenance and evolution of large systems requires cooperation a...

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

network, consisting of circuit packs, ASICs, software units, There are three interdependent factors that drive our software and a craft terminal. Total head count for this release was development processes: interval, quality and cost. As market 180 people and the development project lasted for 19 Dressures continue to demand new features ever more months. rapidly, the challenge is to meet those demands while increasing, or at least not sacrificing, quality. One advantage of defect prevention as an upstream quality improvement practice is the beneficial effect it can have on interval: higher quality early in the process results in fewer defects to be found and repaired in the later parts of the process, thus causing an indirect interval reduction. The NE software is developed in teams of 5-10 people. A typical (large) NE configuration can consist of many different hardware board types and up to 150 different

Software evolution is usually considered in terms of corrections, improvements and enhancements. While helpful, this approach does not take into account the fundamental dimensions of well-engineered software systems (the domains, experience, and process) and how they themselves evolve and affect the evolution of systems for which they are the context. I discuss each dimension, provide examples to illustrate its various aspects and summarize how evolution in that dimension affects system evolution. Only by taking this wholistic approach to evolution can we understand evolution and effectively manage it. 1. Introduction We usually think about the evolution of software systems in terms of the kinds of changes that are made. While the overall motivation of evolution is adaptation, we usually partition these changes into three general classes: corrections, improvements and enhancements. Corrections tend to be fixes of coding errors, but may also range over design, architecture and requirem...

In current change management tools, the actual changes occur outside the tool. In contrast, Infuse concentrates on the actual change process and provides facilities for both managing and coordinating source changes. Infuse provides facilities for automatically structuring the cooperation among programmers, propagating changes, and determining the consistency of changes, and provides a basis for negotiating the resolution of conflicting changes and for iterating over a set of changes. 1. Introduction A number of tools address the problems of managing changes to large software systems. Most such tools provide a framework in which programmers can reserve modules 1 for change and in which the changes themselves occur outside of the tool. Examples include SCCS [Rochkind 75], Cedar's System Modeller [Lampson 83], Darwin [Minsky 85] and DSEE [Leblang 84]. When a change is to be made to a module, a programmer reserves the module, obtains an official copy of the module, and then proceeds b...