|
Article Excerpt
INTRODUCTION
Cognitive work analysis (CWA) and associated techniques focusing on the analysis of work domains are becoming popular methods in the analysis and design of complex systems (Burns, Barsalou, Handlei; Kuo, & Harrigan, 2000; Flach, Eggleston, Kuperman, & Dominguez, 1998; Martinez, Talcott, Bennett, Stansifer, & Shattuck, 2001 ; Naikar & Sanderson, 1999; Potter, Roth, Woods, & Elm, 2000; Reising & Sanderson, 2002; Sanderson, Naikar, Lintern, & Goss, 1999; Vicente & Rasmussen, 1992). Work domain analysis (WDA) is one of the frameworks of CWA (Rasmussen, 1985; Rasmussen, Pejtersen, & Goodstein, 1994) and can be used to gather work domain constraints as part of a cognitive engineering design process. Although several comprehensive resources have introduced and described methods of CWA (e.g., Rasmussen, et al.; Vicente, 1999) and many case studies and research articles have explored the use of such models (e.g., Potter, Elm, Roth, Gualtieri, & Easter, 2002; Reising & Sanderson, 2002; Roth, Lin, Ketch, Kenney, & Sugibayashi, 2001), investigation of correspondence in models within similar domains has received little explicit treatment.
Circumstances arose that allowed such an investigation of model correspondence to be investigated. Over similar lime periods, we performed WDA of two similar command and control systems of naval combat vessels. The first author worked on a Defence R&D Canada project examining the feasibility of using WDA to analyze and provide design recommendations for the future redesign of the command and control system of a Canadian frigate. The other two authors worked in conjunction with the U.S. Navy and defense-oriented corporations to analyze and provide design recommendations for the design of a new class of U.S. naval vessels. Constraints attributable to national security and the corporate, proprietary nature of the information prevented the two groups from sharing information regarding their methods, resultant models, and design outcomes until after both projects had been completed.
Comparing the models that resulted from these two independently conducted yet similar analyses provides a unique opportunity to inspect and comment on the correspondence between these systems' work domain models as well as other models of command and control domains reported in the literature. Although details of physical systems and their implementation will differ, even among very similar domains, one would expect that if methods in WDA are reliably identifying high-level purposes, constraints, and processes that are relevant for design purposes (e.g., display design, function allocation), these facets should be similar across models.
WORK DOMAIN ANALYSIS
Commonly, a WDA is conducted by creating an abstraction hierarchy (AH) according to the principles outlined by Rasmussen (1985). A WDA is a multilevel model of information needs ranging from abstract needs or purposes to concrete needs or physical equipment and physical form. In many instances, the levels of the model include functional purpose (a description of system purposes), abstract function (a description of first principles and priorities), generalized function (a description of processes), physical function (a description of equipment capabilities), and physical form (a description of physical characteristics such as size, shape, color, and location).
Nodes at the different levels are linked through means-end relationships. Moving up along the links through the hierarchy from physical systems to purposes reveals reasons for the existence of the systems (its "ends"), whereas moving down from purposes to systems reveals the means by which the purposes can be achieved. For example, in a command and control environment, a node representing a general process such as "deliver ordnance" would be linked to a higher level purpose of "mission achievement" (the reason for delivering ordnance) as well as a lower level system, such as "missile system" (the means by which the ordnance is delivered). In practice, the AH is typically supplemented by an orthogonal, part-whole decomposition showing systems, subsystems, and components (see Bisantz & Vicente, 1994, for an example). A WDA is usually performed at several levels of detail, depending on the complexity of the system being analyzed. A WDA is performed as a preliminary analysis to identify information needs, critical constraints, and information relationships that are necessary, for successful action and problem management within the domain. In this way, WDA is a useful tool to inform display design.
For clarity, it is important to emphasize what a WDA is not. It is not a model (either descriptive or normative) of how tasks in a domain are performed; it is also not a record or model of generalized or specific instances of expert problem solving or decision making. In capturing fundamental relationships among extant system components, it shares similarities with other types of system engineering models (e.g., functional or structural decompositions). WDA models may be informed and possibly developed by domain experts, but they are aimed at modeling domain knowledge in general, not the knowledge of an individual user or operator.
PROJECT OVERVIEWS AND RESULTANT WORK DOMAIN MODELS
In this section we introduce the two projects, outline the general objectives of each project, note the resources available to each team (which included informal consultations with and/or observations of domain experts, design documentation, and semistructured interviews with domain experts), and describe the work domain models that were developed. Several individuals constituted each project team, of which the authors of the current paper were a subset. Each team included at least one member who had past experience with the WDA methods described earlier (as illustrated in prior studies: e.g., Bisantz & Vicente, 1994; Burns, 2000: Roth et al., 2001).
Project 1: Canadian Ship
The purpose of this project was to examine the feasibility of WDA as an analytical framework for the Canadian HALIFAX class frigate. The HALIFAX class frigate was designed primarily for antisubmarine warfare but in reality must play a role in a variety of missions, including surveillance, escort, information gathering, threat intervention, and delivery of humanitarian aid. The Combat Control System in these ships is scheduled for an upgrade between 2005 and 2010, and in support of this upgrade, new technologies and approaches are being investigated.
The project was not intended to develop complete work domain models for the ship. The intent of the analysis was to support the position of the operations room officer, who is a high-level command officer. Work domain models were expected to support the tasks of situation and threat assessment and of resource management (STA/RM). The tasks of the project were to develop demonstrative work domain models and comment on the feasibility of the approach for this domain. To perform the analysis, team members had access to ship design documentation and operations room officers as domain experts. Several interviews were held with these domain experts in Halifax, Nova Scotia, and training was observed within a full-scope simulator. Other aspects of this project, including the methods used and resultant design recommendations, have been reported in more detail in Burns, Bryant, and Chalmers (2000, 2001, in press).
In developing models for the Canadian ship, we decided to use a three-part model in order to capture the richness of constraints in the domain. One part modeled the ownship, or resource management side. The second part modeled a contact or a situation, and the third part modeled the natural environment. This three-part model resulted...
|
