What situated cognition reveals about work practice--论文代写范文精选

相比之下,模型技术解决问题或正式的政策，是有限的价值沟通,工人和管理者非正式的相互作用，发生在计算机对人机系统设计的总体目标,勃拉姆斯在软件设计过程中为工人提供了关键性的工具。下面的essay代写范文进行详述。

A model of practice is especially useful for revealing informal aspects of work. Conventionally, tools for modeling work produce either detailed descriptions of reasoning, as in cognitive task models (Newell, 1990), or descriptions of work product flows between job functions, as in business process models (Tyo, 1995). These modeling techniques cannot be used to easily or directly represent informal interactions that have a direct effect on the quality of work: how collaborative troubleshooting occurs, how learning occurs on the job, how people work on multiple orders at once, when people engage each other in each other's work, how people use communication media in practice (telephone, e-mail, face-to-face conversation, etc.), and so on. Such factors are circumstantial and conventional and cannot be strictly specified in advance (or controlled by management). Incorporating circumstantial factors in a model of work leads us to consider what people are actually doing, how these practices came about, and whether or not advantageous interactions are emerging. In contrast, models of technical problem solving (as in most cognitive models and expert systems) or formal policies and organization charts ("what should be") are of limited value for communicating to workers and managers alike what informal interactions are occurring and how computer systems, workplace layout, management attitudes, etc. facilitate or hinder such interactions.

More generally, with respect to the overall objectives of human-computer system design, Brahms provides a tool for engaging workers during the software design process, which can be a key aspect of work systems design. In contrast to business reengineering's use of information technology, work system design aims to understand how the computer system and the human system can be most productively integrated. As a model of how work actually occurs, Brahms helps designers understand the context in which computer tools are used (Weickert, 1995). For example, a model of practice reveals how information that is entered into a computer database is first acquired by reading a faxed form, by talking to the person in the next cubicle, or by looking up instructions in a manual. Thus, we approach human-computer interaction from a comprehensive, systemic perspective that seeks to relate how people interact with each other, kinds of representations in the environment, and physical layout of materials (Greenbaum and Kyng, 1991). As we will show, this comprehensive approach provides insights for understanding the human and social factors of software engineering, both in terms of content for representing work processes and in terms of methodology for facilitating the design process. Specifically, by providing a language for representing activities, Brahms improves upon empirical studies and user models that focus only on psychological processes. That is, Brahms models show not only what reasoning occurs, but how the information being used came to be available--based on where the reasoning is occurring, what other tools are being used, who is participating in the problem solving situation, and how (because of other circumstantial physical and social factors) they came to participate.

A cognitive model would of course emphasize that the knowledge of a person affects the quality of the work produced. But a task model of work does not explain how particular people became involved in solving particular problems. Work systems design emphasizes the crucial process by which people reconfigure their organization and tools to bring resources to bear on a given situation. Specifically, who is involved in a situation assessment will determine how the situation is framed (is it a craft problem? a software problem? a management problem? a problem with policy?) and what problem solving methods are applied. In this respect, modeling practice addresses the issues that are raised by the theme of "resource-bounded reasoning" in artificial intelligence research (Zilberstein, 1996) by broadening from issues of how reasoning is managed to how the social-interactional environment determines which agents are involved in reasoning at all about a given problem.

In summary, our approach to practice, work systems design, and model-building in Brahms brings together psychological, social, and physical environmental factors in a coherent manner. As a multi-agent simulation program, Brahms relates traditional engineering approaches to the study of people (e.g., task models) and knowledge-based approaches for representing processes qualitatively. Specifically, agents' behaviors and attention are modeled in Brahms using a rule-based, subsumption architecture (Brooks, 1991; Nakashima, Noda, and Hana, 1996). Behaviors are organized into and inherited from groups to which agents belong; groups include not only technical functions (such as "splicer"), but where people work ("1 World Trade Center people"), their temporary roles ("turf coordinator"), their background ("new hire from outside the company"), and the tools they use ("CIMAP database users"). Most importantly, we model located behaviors of people in time and view the rule-like constructs in the model as descriptions of what people do, not what they know per se.

Because Brahms' design is a combination of process modeling and situated cognition ideas, additional preliminary discussion is helpful to understand what we seek to include in Brahms models (hence why other tools are inadequate) and how our methods and objectives relate to the field of artificial intelligence more broadly. The following section uses an example to relate Brahms relates to situated cognition theories.

Overview of situated cognition
Situated cognition is an approach for understanding cognition that seeks to relate social, neural, and psychological views (Clancey, 1997b). From the social perspective, situated cognition provides insights about the content of knowledge, namely how people conceive of what they are doing in terms of their contribution to a community of practice (Wenger, 1997) and how this affects their attention and priorities over time. From the neural perspective, situated cognition provides insights about the physical structure of knowledge, namely how perception, conception, and motor action are related through a self-organizing coordination process with a memory. From a psychological perspective, situated cognition provides insights about how behavior is improvised by resequencing and recomposing previous behaviors.

These considerations are much more complicated than the traditional "symbolic" view of knowledge. There are many implications for understanding human learning, the use of tools, and how to design tools. For example, situated cognition suggests that issues of identity are central to understanding a person's motivation for using a tool. From the psychological side, situated cognition reveals the interpretative, conceptual work involved in dealing with a business policy. In turn, these insights better reveal the nature of "routine" work and "problematic situations" (Schon, 1983; Wynn, 1991).
In short, a situated cognition perspective suggested that we improve business process models by representing task performance within the context of social-interactional behaviors. In this way, we are drawn to consider how psychological, social, and physical factors interact to affect what is normally taken for granted by problem solving models, namely how people make observations (gaining new information), how people prioritize their tasks while juggling multiple responsibilities, and how they decide whether and by what means to communicate information. Simply put, a straight-forward knowledge-based approach to modeling an office would suggest that people are literally following their job function descriptions, and hence doing the same thing at 9 AM as at 4:45 PM, that they are either knowledge clones or in need of training, that they are never working on other people's problems, that they do not answer a phone on someone else's desk, etc.

Models can be built at different levels to describe different phenomena. But the constructs in a modeling language often reflect assumptions about what a model should include. Specifically, the original paradigm of expert systems (Hayes-Roth, Waterman, and Lenat, 1983) assumes that knowledge is exclusively technical, objective, and used for reasoning. In the original formulation, all human action is viewed as being problem solving in an unspecified environment. At issue is not so much the modeling apparatus (though indeed more is needed to model human attention and physical interaction), but the concepts used for describing human behavior. Specifically, expert systems did not represent the conceptual and physical context in which reasoning occurs, which we call work practice.

The analysis of work practice originated in the social sciences, particularly anthropology and the ecological approach to sociology called situated action (Mills, 1940). The application to work systems design is perhaps most evident in socio-technical systems approaches in the 1950s (Emery and Trist, 1960). We were specifically most influenced by the research on situated action collected in Design at Work (Greenbaum and Kyng, 1991). Simply put, the situated action perspective claims that the quality of work (including the quality of software design) depends on circumstantial, physical interaction with materials and who participates: 
 
The designer must reverse the field, pull the background into the foreground, and begin to see how portions of behavior function as a part of the process. The workplace doesn't consist exclusively of manipulating symbols or materials that have predictable properties under specific conditions, that can be formulaically arranged to produce a certain outcome. It is based on a background of practices, in fact, practices within practices. Imagine asking somehow how he swims. Even if he could describe the movements adequately, he probably would not mention the pre-condition: You have to be in water, alive. (Wynn, 1991)

But business process models are useful because they abstract away details. What aspects of the "background of practices" should be considered? How can modeling practice be usefully scoped and focused? That is the key problem we had to address in developing Brahms. Based on our analyses of task/workflow models (e.g., see Joosten and Brinkkemper, 1996), and given our objective of incorporating informal, circumstantial factors that influence work quality, we concluded that a model of practice should primarily 1) represent the daily activities during which tasks are carried out and 2) attempt to comprehensively model when and how conversations occur. The next subsection provides an example of the level of detail business process models omit, which we hypothesized should be included if we are to understand how collaboration actually occurs.

51Due网站原创范文除特殊说明外一切图文著作权归51Due所有；未经51Due官方授权谢绝任何用途转载或刊发于媒体。如发生侵犯著作权现象，51Due保留一切法律追诉权。（essay代写)
更多essay代写范文欢迎访问我们主页 www.51due.com 当然有essay代写需求可以和我们24小时在线客服 QQ:800020041 联系交流。-X（essay代写)