In 2002, the authors and their colleagues proposed some preliminary guidelines for empirical software engineering research. In this paper, we revisit them. We believe that for the purpose of supporting the development of project-based bespoke software, they still perform reasonably well. However, the worlds of software and software engineering have changed dramatically in the last 25 years. We suggest that new guidelines are needed to respond to changes in software practices, including the possibility of regulation of AI-based software products, and propose the scope of such guidelines.

We present a framework for describing insiders and their actions based on the organization, the environment, the system, and the individual. Using several real examples of unwelcome insider action (hard drive removal, stolen intellectual property, tax fraud, and proliferation of e-mail responses), we show how the taxonomy helps in understanding how each situation arose and could have been addressed. The differentiation among types of threats suggests how effective responses to insider threats might be shaped, what choices exist for each type of threat, and the implications of each. Future work will consider appropriate strategies to address each type of insider threat in terms of detection, prevention, mitigation, remediation, and punishment.

We analyzed data from 145 maintenance and development projects managed by a single outsourcing company, including effort and duration estimates, effort and duration actuals, and function points counts. The estimates were made as part of the company’s standard project estimating process that involved producing two or more estimates for each project and selecting one estimate to be the basis of client-agreed budgets. We found that effort estimates chosen as a basis for project budgets were, in general, reasonably good, with 63% of the estimates being within 25% of the actual value, and an average absolute error of 0.26. These estimates were significantly better than regression estimates based on adjusted function points, although the function point models were based on a homogeneous subset of the full data set, and we allowed for the fact that the model parameters changed over time. Furthermore, there was little evidence that the accuracy of the selected estimates was due to their becoming the target values for the project managers.

Empirical software engineering research needs research guidelines to improve the research and reporting processes. We propose a preliminary set of research guidelines aimed at stimulating discussion among software researchers. They are based on a review of research guidelines developed for medical researchers and on our own experience in doing and reviewing software engineering research. The guidelines are intended to assist researchers, reviewers, and meta-analysts in designing, conducting, and evaluating empirical studies. Editorial boards of software engineering journals may wish to use our recommendations as a basis for developing guidelines for reviewers and for framing policies for dealing with the design, data collection, and analysis and reporting of empirical studies.

Shari Lawrence Pfleeger The precipitous decline in women's enrollment in computer science since 1984 has to be addressed in new and creative ways. We must broaden our horizons and think of our students not only as potential compiler or operating systems designers but also as implementers of computerbased solutions to non-computing problems. There is a general trend, among women as well as men, to want to apply computing skills to a wide variety of disciplines outside the traditional software businesses. (Washington Post, 16 August 2000, Business section, p. 1). We can leverage this interest not by watering down our computer science curricula but by strengthening them and adding internships and team projects that apply skills to these outside disciplines. With such a program, a woman interested in finance might be attracted to a CS degree that enables her to intern at a brokerage house, bank, or insurance company, for example. Thus, we can expand from a degree in computing for computing's sake to computing and its place in the wider world. Such an approach appears to be successful in the UK, where departments of computing offer specializations in computer science, information science, and software engineering, often in partnership with industries that provide internships or support for team projects.

As we maintain systems and build new ones, we have to make decisions about when to use old technology and when to adopt new ones. Especially when using components, we must decide when to use an old one whole, when to modify it, and when to create a new one. In this talk, I will look at such changes in the larger context of how we make decisions about adopting new technology. We will see that the decision-making must involve information in three arenas: technological, organizational and evidential. That is, we must know not only about the contrast between the old and new technologies, but also about the characteristics of the receiving organization, and the credibility of the evidence that the new technology is an improvement over the old.

No abstract available.

are glad that members of the software engineering communityhave taken-up our suggestion that metric validation needs publicdebate. With respect to specific issues raised by Basili et al. in theirletter, clearly, we disagree with their view that we are seriouslyimpeding the appropriate definition of attributes; we are glad tohave the opportunity to clarify some of our arguments.

In this paper we propose a framework for validating software measurement. We start by defining a measurement structure model that identifies the elementary component of measures and the measurement process, and then consider five other models involved in measurement: unit definition models, instrumentation models, attribute relationship models, measurement protocols and entity population models. We consider a number of measures from the viewpoint of our measurement validation framework and identify a number of shortcomings; in particular we identify a number of problems with the construction of function points. We also compare our view of measurement validation with ideas presented by other researchers and identify a number of areas of disagreement. Finally, we suggest several rules that practitioners and researchers can use to avoid measurement problems, including the use of measurement vectors rather than artificially contrived scalars.

The authors introduce a software maintenance process model that emphasizes impact analysis and forms a framework for software maintenance metrics support. Schedule, resource, and other constraints frequently subvert efforts to build and maintain a software product. using direct graphs, the authors suggest traditional process and product metrics, as well as new impact analysis metrics that address software work-product traceability and inter-work-product dependencies. Management can use these and other metrics to understand and control the maintenance process dynamically. As changes are requested, measurements can be made, impact assessed, and implementation decisions made. Moreover, the more the impact is understood, the better the change can be controlled; hence risks are minimized.>