Search

A design education program must unite traditionally siloed disciplines, spanning rigid academic boundaries from engineering to social sciences. Work to establish the Kyoto University Design School had to meet these challenges in promoting interdisciplinary cooperation and provides a solid model for others to build on. The web extra at https://youtu.be/bTWoIew-lpg features interviews and further details about Kyoto University Design School's innovative curriculum. [ABSTRACT FROM PUBLISHER]

The article discusses the scarcity of domain expertise in software development. Focus is given on the implications of thinning demarcation line between users and developers. The authors believe that empowering domain experts can be done by developing systems that are "underdesigned" to allow domain experts to appropriate and adapt thus creating their own solutions. They created a metadesign framework which is composed of objectives, techniques, and processes for software development activities.

Empirical software engineering can be viewed as a series of actions to obtain knowledge and a better understanding about some aspects of software development given a set of problem statements in the form of issues, questions or hypotheses. Our experience in conducting empirical software engineering from a variety of viewpoints for the last decade has made us aware of the criticality of integrating the various types of data that are collected and analyzed as well as the criticality of integrating the various types of activities that take place such as experiment design and the experiment itself. This has led us to develop a Computer-Aided Empirical Software Engineering (CAESE) framework as a substrate for supporting the empirical software engineering lifecycle. CAESE supports empirical software engineering in the same manner as a CASE environment serves as a substrate for supporting the software development lifecycle. This paper first presents the CAESE framework that consists of three elements. The first element is a process model for the "lifecycle" of empirical software engineering studies, including needs analysis, experiment design, actual experimentation, and analyzing and packaging results. The second element is a model that helps empirical software engineers decide how to look at the "world" to be studied in a coherent manner. The third element is an architecture based on which CAESE environments can be built, consisting of tool sets for each phase of the process model, a process management mechanism, and the two types of integration mechanism that are vital for handling multiple types of data: data integration and control integration. The second half of this paper describes the Ginger2 environment as an instantiation of our framework. The paper concludes with reports on case studies using Ginger2, which dealt with a variety of empirical data types including mouse and keystrokes, eye traces, three- dimensional movement, skin resistance level, and video-taped data. [ABSTRACT FROM AUTHOR]

Focuses on the development of software products for other cultures. Internationalization and localization; Cross-cultural software development; Intracultural cultures.

The field of knowledge-based software engineering has been undergoing a shift in emphasis from automatic programming to human augmentation. We support this shift with an approach that embeds human-computer cooperative problem-solving tools into knowledge-based design environments that work in conjunction with human software designers in specific application domains. Domain orientation reduces the large conceptual distance between problem-domain semantics and software artifacts. Integrated environments support the co-evolution of specification and construction while allowing designers to access relevant knowledge at each stage of a software development process. The access and development of knowledge is supported in a cycle of location, comprehension, and modification. Modification includes the evolution of the knowledge base and tools. A framework for building such tools and mechanisms is described and illustrated in terms of three systems: CATALOGEXPLORER, EXPLAINER, and MODIFIER. User studies of these systems demonstrate the promises and limitations of our design environment approach. [ABSTRACT FROM AUTHOR]

Software designers make decisions covering a wide variety of aspects of the software to be designed through nested, intertwined processes. Some of these dependencies among design decisions might not be obvious, especially for people who didn't start with the project at the beginning of the design process. Extending or altering an existing design decision without fully understanding its dependencies might result in a deterioration of the quality of the software design. Design practice streams (DPS) tools help designers browse the segments of video data relevant to a particular topic by specifying a region on a whiteboard or by choosing a few terms used in a meeting transcript to further investigate the point of interest effectively. [ABSTRACT FROM PUBLISHER]