Having recently participated in the Doctoral Consortium of the Australasian Computing Education Conference I was struck by the core methodological challenges faced by students. Initial proposals seemed to be along the lines of, "well I will need a control group and a comparison group to evaluate x or y condition or intervention." The corollary to this thinking then became "well how many students will be enough?" presumably so the findings could be generalisable in some manner. Yet do methods drawn from the natural sciences really furnish the most appropriate approaches for computing education research (CER), with its hybrid concerns of technology and people? If not, then which methods would be more suitable and how can students be guided towards their adoption? Development, 18, 2 (1999): 165-172.

An important problem in program development and maintenance is version control, i.e. the task of keeping a software system consisting of many versions and configurations well organized. The Revision Control System (RCS) is a software tool that assists with that task. RCS manages revisions of text documents, in particular source programs, documentation, and test data. It automates the storing, retrieval, logging and identification of revisions, and it provides selection mechanisms for composing configurations. This paper introduces basic version control concepts and discusses the practice of version control using RCS. For conserving space, RCS stores deltas, i.e. differences between successive revisions. Several delta storage methods are discussed. Usage statistics show that RCS's delta method is space and time efficient. The paper concludes with a detailed survey of version control tools.

ÐSoftware design patterns package proven solutions to recurring design problems in a form that simplifies reuse. We are seeking empirical evidence whether using design patterns is beneficial. In particular, one may prefer using a design pattern even if the actual design problem is simpler than that solved by the pattern, i.e., if not all of the functionality offered by the pattern is actually required. Our experiment investigates software maintenance scenarios that employ various design patterns and compares designs with patterns to simpler alternatives. The subjects were professional software engineers. In most of our nine maintenance tasks, we found positive effects from using a design pattern: Either its inherent additional flexibility was achieved without requiring more maintenance time or maintenance time was reduced compared to the simpler alternative. In a few cases, we found negative effects: The alternative solution was less error-prone or required less maintenance time. Although most of these effects were expected, a few were surprising: A negative effect occurs although a certain application of the Observer pattern appears to be well justified and a positive effect occurs despite superfluous flexibility (and, hence, complexity) introduced by a certain application of the Decorator pattern. Overall, we conclude that, unless there is a clear reason to prefer the simpler solution, it is probably wise to choose the flexibility provided by the design pattern because unexpected new requirements often appear. We identify several questions for future empirical research.

A survey of over 400 recent research articles suggests that computer scientists publish relatively few papers with experimentally validated r esults.The survey includes complete volumes of several refereed c omputer science journals, a conference, and 50 titles drawn at random from all articles published b y A CM in 1993. The journals Optical Engineering OE and Neural Computation NC were used for comparison.Of the papers in the random sample that would require experimental validation, 40 have none at all. In journals related to software engineering, this fraction is over 50 . In comparison, the fraction of papers lacking quantitative evaluation in OE and NC is only 15 and 12 , respectively.Conversely, the fraction of papers that devote one fth or more of their space to experimental validation is almost 70 for OE and NC, while it is a mere 30 for the CS random sample and 20 for software engineering.The low ratio of validated r esults appears to be a serious weakness in computer science r esearch. This weakness should be r e cti ed for the long-term health of the eld.

Classifying requirements is crucial for automatically handling natural language requirements. The performance of existing automatic classification approaches diminishes when applied to unseen projects because requirements usually vary in wording and style. The main problem is poor generalization. We propose NoRBERT that fine-tunes BERT, a language model that has proven useful for transfer learning. We apply our approach to different tasks in the domain of requirements classification. We achieve similar or better results (F 1 -scores of up to 94%) on both seen and unseen projects for classifying functional and non-functional requirements on the PROMISE NFR dataset. NoRBERT outperforms recent approaches at classifying nonfunctional requirements subclasses. The most frequent classes are classified with an average F 1 -score of 87%. In an unseen project setup on a relabeled PROMISE NFR dataset, our approach achieves an improvement of 15 percentage points in average F 1score compared to recent approaches. Additionally, we propose to classify functional requirements according to the included concerns, i.e., function, data, and behavior. We labeled the functional requirements in the PROMISE NFR dataset and applied our approach. NoRBERT achieves an F 1 -score of up to 92%. Overall, NoRBERT improves requirements classification and can be applied to unseen projects with convincing results.