Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest. The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet--something to make software costs drop as rapidly as computer hardware costs do. But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. In this article, I shall try to show why, by examining both the nature of the software problem and the properties of the bullets proposed. Skepticism is not pessimism, however. Although we see no startling breakthroughs--and indeed, I believe such to be inconsistent with the nature of software--many encouraging

©2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Abstract. Abstraction identification is named as a key problem in requirements analysis. Typically, the abstractions must be found among the large mass of natural language text collected from the clients and users. This paper motivates and describes a new approach, based on traditional signal processing methods, for finding abstractions in natural language text and offers a new tool, AbstFinder as an implementation of this approach. The advantages and disadvantages of the approach and the design of the tool are discussed in detail. Various scenarios for use of the tool are offered. Some of these scenarios were used in case study of the effectiveness of the tool on an industrial-strength example of finding abstractions in a request for proposals.

We identify and analyze basic principles which necessarily underlie software measures research. In the prevailing paradigm for the validation of software measures there is a fundamental assumption that the sets of measured documents are ordered, and that measures should report these orders. We describe mathematically the nature of such orders. Consideration of these orders suggests a hierarchy of software document measures, a methodology for developing new measures, and a general approach to the analytical evaluation of measures. We also point out the importance of units for any type of measurement and stress the perils of equating document structure complexity and psychological complexity. Keywords: software measures, abstractions of software documents, software structure, analytical evaluations of measures 1 Introduction This paper presents some underlying principles for software measures research. By "software measures" we mean measures which are obtainable directly from software d...

Time and motion studies are a proven means toward understanding and improving any engineering enterprise. We believe that the engineering of software processes is no different in this respect; however, the fact that software development yields an intellectual --- as opposed to physical --- product calls for new and creative measurement techniques. In attempting to answer the question "Where does time go in software development?" we have been experimenting with several forms of data collection. We have found that two techniques in particular, time diaries and direct observation, are feasible and yield useful information about time utilization. The major source of discrepancy between them is granularity: most software developers can not retrospectively report with a high degree of accuracy the large number of interruptions and unplanned transitory events that typically characterize their working day. Drawing upon experimental techniques from the behavioral sciences, we used three alterna...

Anyone who has taught object-oriented domain analysis or any other software process requiring concept identification has undoubtedly observed that some students just don’t get it. Our evaluation of the work of over 740 University of Waterloo students on over 135 Software Requirements Specifications during the last four years supports this same observation. The students ’ task was to specify a telephone exchange or a voice-over-IP telephone system and the related accounts management subsystem, based on models they developed using object-oriented analysis. A detailed comparative study of three much smaller specifications, all of an elevator system, suggests that object orientation is poorly suited to domain analysis, even of small-sized domains, and that the difficulties we have observed are independent both of the size of the system under specification and of the overall abilities of the students. 1

Simulation is an educational tool that is commonly used to teach processes that are infeasible to practice in the real world. Software process education is a domain that has not yet taken full advantage of the benefits of simulation. To address this, we have developed SimSE, an educational, interactive, graphical environment for building and simulating software engineering processes in a game-like setting. We detail the design of SimSE, present an initial simulation model of a waterfall process that we developed, and describe an experiment that we conducted to evaluate the educational potential of SimSE and its initial model. 1.

How long do different programmers take to solve the same task? In 1967, Grant and Sackman published their now famous number of 28:1 interpersonal performance differences, which is both incorrect and misleading. This report presents the analysis of a much larger dataset of software engineering work time data with respect to the same question. It corrects the false 28:1 value, proposes more appropriate metrics, presents the results for the larger dataset, and presents results of several further analyses: distribution shapes, effect sizes, and the performance of various significance tests. 2 CONTENTS Contents 1 The 1966 experiment of Grant and Sackman 3 1.1 28:1 just isn't true! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 How should we measure variability? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Only 12 programmers even after 30 years? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Overview of this r...

Learning from high performance projects is crucial for software process improvement. Therefore, we need to identify outstanding projects that may serve as role models. It is common to measure productivity as an indicator of performance. It is vital that productivity measurements deal correctly with variable returns to scale and multivariate data. Software projects generally exhibit variable returns to scale, and the output from ERP projects is multivariate. We propose to use Data Envelopment Analysis Variable Returns to Scale (DEA VRS) to measure the productivity of software projects. DEA VRS fulfils the two requirements stated above, and to our knowledge, it is the only method complying with them. The results from this empirical study of 30 ERP projects extracted from a benchmarking database in Accenture identified six projects as potential role models. These projects deserve to be studied and probably copied as part of a software process improvement initiative. The results also suggest that there is a 50 % potential for productivity improvement, on average. Finally, the results support the assumption of variable returns to scale in ERP projects. We recommend DEA VRS be used as the default technique for appropriate productivity comparisons of software projects. Used together with methods for hypothesis testing, DEA VRS is also a useful technique for assessing the effect of alleged process improvements.

Abstract: This article examines the academic substance of software engineering. It identifies the basic research questions and the methods used to solve them. What is learned during this research constitutes the body of knowledge of software engineering. The article then discusses at length what about software makes its production so difficult and makes software engineering so challenging an intellectual discipline. 1