The problems of designing large software systems were studied through interviewing personnel from 17 large projects. A layered behavioral model is used to analyze how three lgf these problems-the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication bottlenecks and breakdowns-affected software productivity and quality through their impact on cognitive, social, and organizational processes.

Research into the cognitive aspects of programming originated in the study of professional programmers (whether experts or students). Even "end-user" programmers in previous studies have often worked in organizations where programming is recognized to be demanding professional work- the term 'vower-user" recognizes this technical kudos. But as personal computers become widespread, and most new domestic appliances incorporate microprocessors, many people are engaging in programming-like activities in domestic or non-professional contexts. Such users often have less motivation and more obstacles to programming, meaning that they may be unlikely even to take the first steps. This paper analyses the generic nature of those first steps, and identifies the cognitive demands that characterize them. On the basis of this analysis we propose the Attention Investment model, a cognitive model of programming that offers a consistent account of all programming behaviour, from professionals to end-users.

Interfaces to databases have traditionally been designed as single-user systems that hide other users and their activity. This paper aims to show that collaboration is an important aspect of searching online information stores that requires explicit computerised support. The claim is made that a truly user-centred system must acknowledge and support collaborative interactions between users. Collaborative working implies a need to share information: both the search product and the search process. Searches need not be restricted to inanimate resources but people can also search for other people. The ARIADNE system is introduced as an example of computerised support for collaboration between browsers. A number of systems offering varied approaches to supporting collaboration are surveyed and a structure for analysing the various aspects of collaboration is applied.

In this paper we review the literature relating to the psychological/educational study of programming. We identify general trends comparing novice and expert programmers, programming knowledge and strategies, program generation and comprehension, and objectoriented versus procedural programming. (We do not cover research relating specifically to other programming styles.) The main focus of the review is on novice programming and topics relating to novice teaching and learning. Various problems experienced by novices are identified, including issues relating to basic program design, to algorithmic complexity in certain language features, to the ‘‘fragility’ ’ of novice knowledge, and so on. We summarise this material and suggest some practical implications for teachers. We suggest that a key issue that emerges is the distinction between effective and ineffective novices. What characterises effective novices? Is it possible to identify the specific deficits of ineffective novices and help them to become effective learners of programming? 1.

We proposed a new approach for the construction of grammars and parsers for existing languages. The approach is both very powerful and simple. We provided a structured process and explained our methods in detail so that others can apply our ideas for their own grammar construction activities. We illustrated the proposed approach with a nontrivial case study. Using our process, we constructed in a few weeks a complete and correct VS COBOL II grammar specification for IBM mainframes. We not only constructed a parser for it, but also published a web-enabled grammar specification so that others can use this result to conveniently construct their own grammar-based tools for VS COBOL II, or derivatives.

Approximately 70 % of the source code of a software system consists of identifiers. Hence, the names chosen as identifiers are of paramount importance for the readability of computer programs and therewith their comprehensibility. However, virtually every programming language allows programmers to use almost arbitrary sequences of characters as identifiers which far too often results in more or less meaningless or even misleading naming. Coding style guides address this problem but are usually limited to general and hard to enforce rules like “identifiers should be self-describing”. This paper renders adequate identifier naming far more precisely. A formal model, based on bijective mappings between concepts and names, provides a solid foundation for the definition of precise rules for concise and consistent naming. The enforcement of these rules is supported by a tool that incrementally builds and maintains a complete identifier dictionary while the system is being developed. The identifier dictionary explains the language used in the software system, aids in consistent naming, and improves productivity of programmers by proposing suitable names depending on the current context.

Theoretical models and experimental results relevant to the study of behavioral issues in the use of text editors--including both those intended primarily for computer program development and those intended for manuscript preparation--are examined. Models can predict editing task time in terms of elementary activities, in an error-free environment,

George Santayana's statement, "Those who cannot remember the past are condemned to repeat it, " is only half true. The past also includes successful histories. If you haven't been made aware of them, you're often condemned not to repeat their successes. In a rapidly expanding field such as software engineering, this happens a lot. Extensive studies of many software projects such as the Standish Reports offer convincing evidence that many projects fail to repeat past successes. This paper tries to identify at least some of the major past software experiences that were well worth repeating, and some that were not. It also tries to identify underlying phenomena influencing the evolution of software engineering practices that have at least helped the author appreciate how our field has gotten to where it has been and where it is. A counterpart Santayana-like statement about the past and future might say, "In an era of rapid change, those who repeat the past are condemned to a bleak future. " (Think about the dinosaurs, and think carefully about software engineering maturity models that emphasize repeatability.) This paper also tries to identify some of the major sources of change that will affect software engineering practices in the next couple of decades, and identifies some strategies for assessing and adapting to these sources of change. It also makes some first steps towards distinguishing relatively timeless software engineering principles that are risky not to repeat, and conditions of change under which aging practices will become increasingly risky to repeat.

Large amounts of Java software have been written since the language’s escape into unsuspecting software ecology more than ten years ago. Surprisingly little is known about the structure of Java programs in the wild: about the way methods are grouped into classes and then into packages, the way packages relate to each other, or the way inheritance and composition are used to put these programs together. We present the results of the first in-depth study of the structure of Java programs. We have collected a number of Java programs and measured their key structural attributes. We have found evidence that some relationships follow power-laws, while others do not. We have also observed variations that seem related to some characteristic of the application itself. This study provides important information for researchers who can investigate how and why the structural relationships we find may have originated, what they portend, and how they can be managed. Categories and Subject Descriptors D.2.8 [SOFTWARE ENGI-NEERING]: Metrics—Product metrics; D.1.5 [PROGRAMMING

Abstract not found