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.

Domain-oriented design environments are cooperative problem-solving systems that support designers in complex design tasks. In this paper we present the facilities and architecture of Argo, a domain-oriented design environment for software architecture. Argo’s architecture is motivated by the desire to achieve reuse and extensibility of the design environment. It separates domain-neutral code from domain-oriented code, which is distributed among intelligent design materials as opposed to being centralized in the design environment. Argo’s facilities are motivated by the observed cognitive needs of designers. These facilities extend previous work in design environments to support reflection-in-action, opportunistic design, and comprehension and problem-solving. Keywords: Domain-oriented design environments, critics, software architectures, architectural styles, humancomputer interaction, human cognitive skills.

Program comprehension is a complex problem solving process. We report on an experiment that studies expert programmers’ comprehension behavior in the context of modifying a complex PASCAL program. Our data suggests that program comprehension is best understood as a goal– oriented, hypotheses-driven problem–solving process. Programmers follow a pragmatic as-needed rather than a systematic strategy, they restrict their understanding to those parts of a program they find relevant for a given task, and they use bottom-up comprehension only for directly relevant code and in cases of missing, insufficient, or failing hypotheses. These findings have important consequences for the design of cognitively adequate computer–aided software engineering tools.

. The ways in which we approach systems development practice and research play a major role in shaping professional development within our field. This paper investigates a particular approach, Reflective Systems Development, which has been developed over the past twenty years by a small group of mainly Danish researchers in collaboration with practitioners and students. In this approach, researchers focus on how computer-based information systems are developed in practice; they emphasize the important role played by the local organizational environment; and they combine interpretive understandings of practice with normative propositions to support professional development. The purpose of the paper is to present and evaluate the underlying assumptions and practices of Reflective Systems Development focusing on the following questions: How should we understand, support, and improve practice ? How should we organize and conduct research? How should we relate practice and...

Abstract Reports from a systems development research tradition in which emphasis is put on relating research activities to practice and on establishing fruitful collaboration between groups of researchers and practitioners. Describes and evaluates a specific research project in which a large group of researchers and practitioners worked together to understand, support, and improve systems development practices in four organisations over a period of three years. Uses the case to reflect on the research goals, approaches, and results involved in this tradition for researching systems development practice. Proposes collaborative practice research as a way to organise and conduct research into systems development practice based on close collaboration between researchers and practitioners. Exemplifies the use of pluralist research methodology by combining action research with experiments and conventional practice studies. Argues that collaborative practice research offers one practical way to strike a useful balance between relevance and rigour. Concludes with a discussion of the implications for the relation between research and practice within the systems development discipline and with lessons on how to design research efforts as collaborations between researchers and practitioners. 1

We present results of observing professional maintenance engineers working with industrial code at actual maintenance tasks. Protocol analysis is used to explore how code understanding might differ for small versus large scale code. The experiment confirms that cognition processes work at all levels of abstraction simultaneously as programmers build a mental model of the code. Cognition processes emerged at three levels of aggregation representing lower and higher level strategies of understanding. They show differences in what triggers them and how they achieve their goals. Results are useful for defining core competencies which maintenance engineers need for their work and for documentation and development standards. 1 Introduction During maintenance and software evolution, software engineers must understand code they haven't written for a variety of tasks. Existing cognition models [1, 4, 5, 6, 7, 10] emphasize cognition by what the program does (a functional approach) and how th...

Maintenance frequently consumes more resources than new software development. A major portion of the maintenance effort is spent on the reverse engineering activity of understanding existing software. If we can learn more about how programmers understand code successfully, we can build better tools to support the understanding process. This contributes to higher quality and improved efficiency of maintenance tasks. We present an integrated code comprehension model and our experiences with it in an industrial setting. We use audio-taped, think-aloud reports to investigate how well our integrated code comprehension model works during industrial maintenance activities ranging from code fixes to enhancements, code leverage, and reuse. We analyze the tapes for information needs during maintenance activities and derive tool capabilities accordingly. 1 Introduction Maintenance typically requires more resources than new software development. A significant portion of the maintenance effort in...

Software architectures are high-level design representations of software systems that focus on composition of software components and how those components interact. Software architectures abstract the details of implementation and allow the designer to focus on essential design decisions. Regardless of notation, designers are faced with the task of making good design decisions, which demands a wide range of knowledge of the problem and solution domains. Argo is a software architecture design environment that supports designers by addressing several cognitive challenges of design. In this paper we describe how Argo supports decision making by automatically supplying knowledge that is timely and relevant to decisions at hand.

This test is a pre-print of Visser, W. (1992). Designers ’ activities examined at three levels: organization, strategies & problem-solving. Knowledge-Based Systems, 5(1), 92-104.

Design critiquing systems are a type of intelligent user interface used to support human designers in decision making. This paper places design critics in the larger context of intelligent user interface approaches and surveys several critiquing systems. Each approach and system is evaluated with respect to a five-phase design improvement process. This paper concludes with a summary of the state of the art in critiquing systems and recommendations for future research directions. 1.