Evaluating Opportunities for Design Capture

A key motive for developing ways to structure and preserve records of decision-making in software development is the belief that the high cost of system maintenance could be reduced by providing access to these records. Development projects vary widely. Tools and methods can be appropriate for one development environment but not for another. In this ch apter, I describe four kinds of software development environments and outline the opportunities and obstacles for using design rationale in each. Some devel opment projects have good reason to avoid investing resources early in development, even when great benefits may accrue later. Many off-the-shelf product development efforts are arguably of this nature. In other projects, such as customized software development, the value of upstream investment seems more compelling. I reflect on the difficulty of learning from failed projects and on the need for researchers to distinguish carefully between the requirements of science and those of engineering.

[1]  Colin Potts.  Supporting software design: integrating design methods and design rationale , 1996 .

[2]  Raymond McCall,et al.  Making argumentation serve design , 1991 .

[3]  Barry W. Boehm,et al.  Software Engineering Economics , 1993, IEEE Transactions on Software Engineering.

[4]  J. F. Traub,et al.  Scaling Up: A Research Agenda for Software Engineering , 1989 .

[5]  M. E. Conway.  HOW DO COMMITTEES INVENT , 1967 .

[6]  Barry W. Boehm,et al.  A spiral model of software development and enhancement , 1986, Computer.

[7]  Jonathan Grudin,et al.  Why CSCW Applications Fail: Problems in the Design and Evaluation of Organization of Organizational Interfaces. , 1988 .

[8]  Tracy Kidder,et al.  Soul of a New Machine , 1981 .

[9]  A.P.J. Jarczyk,et al.  Design rationale for software engineering: a survey , 1992, Proceedings of the Twenty-Fifth Hawaii International Conference on System Sciences.

[10]  Charles F. Martin.  User-Centered Requirements Analysis , 1988 .

[11]  Andrew Dillon,et al.  Design rationale: Concepts, techniques, and use , 1997 .

[12]  Jonathan Grudin,et al.  Groupware and social dynamics: eight challenges for developers , 1994, CACM.

[13]  Simon Buckingham Shum,et al.  Analyzing the Usability of a Design Rationale Notation , 1996 .

[14]  Brigham Bell,et al.  Problem-Centered Design for Expressiveness and Facility in a Graphical Programming System , 1996, Hum. Comput. Interact..

[15]  Jonathan Grudin,et al.  Interactive systems: bridging the gaps between developers and users , 1991, Computer.

[16]  Thomas P. Moran,et al.  Questions, Options, and Criteria: Elements of Design Space Analysis , 1991, Hum. Comput. Interact..

[17]  Jonathan Grudin,et al.  Supporting Indirect Collaborative Design With Integrated Knowledge-Based Design Environments , 1992, Hum. Comput. Interact..

[18]  Jonathan Grudin,et al.  Systematic Sources of Suboptimal Interface Design in Large Product Development Organizations , 1991, Hum. Comput. Interact..

[19]  Bill Curtis,et al.  A field study of the software design process for large systems , 1988, CACM.

[20]  Bob Anderson,et al.  Organizational Innovation and the Articulation of the Design Space , 1996 .

[21]  GrudinJonathan,et al.  Supporting indirect collaborative design with integrated knowledge-based design environments , 1992 .

[22]  G. R. Gladden.  Stop the life-cycle, I want to get off , 1982, ACM SIGSOFT Softw. Eng. Notes.

[23]  Mary Beth Rosson,et al.  Deliberated Evolution: Stalking the View Matcher in Design Space , 1991, Hum. Comput. Interact..

[24]  Thomas R. Gruber,et al.  Generative Design Rationale: Beyond the Record and Replay Paradigm , 1996 .

[25]  E. Jeffrey Conklin,et al.  A process-oriented approach to design rationale , 1991 .