Leveraging Existing Hypertext Functionality to Create A Customized Environment for Team Analysis

Albert M. Selvin
Network Planning and Engineering Systems Laboratory
NYNEX Science & Technology
400 Westchester Ave.
White Plains, NY USA 10604
selvin@nynexst.com

Abstract

Effective comprehension of problem domains by teams requires both structured and unstructured approaches. This paper describes a modeling technique that marries an issue-based hypertext tool with a structured systems analysis approach. The principal contribution of this technique is to combine the activities of structured modeling with facilitated exploratory conversation about the issues raised by the modeling effort, as well as other issues of importance to the project team. The technique links the two kinds of discourse together in a free-form, multi-dimensional, searchable database, without requiring programming skills or excessive administration. The intended users of the technique are participants in efforts to model complex problem domains (such as business process redesign or computer system implementation). The approach provides rules and specifications for model-building, specialized hyperlinking techniques, and other methods to allow construction and maintenance of effective "model-bases".

INTRODUCTION

Not all work in a model-building process is the work of actually populating a model with model elements. Much of the group work that occurs in a model-building effort consists of discussion, argument, brainstorming, and other more or less informal communication about the models. This includes conversation about what to put in the model, what issues are raised by the model, what work needs to be done in connection with the model, how does the model relate to other aspects of the project, and so on.

Most modeling tools do not include support for these activities, and, more significantly, do not provide any way of recording, displaying, or maintaining these discussions as part of the overall modeling representation. Modeling and conversation are seen as, and supported as, separate activities requiring separate (if any) tools. This has important negative implications for development of group understanding of both the models and the problem domain, the communicative ability of both the project team as a whole and the team's individual members, the storing of rationale for key decisions about model elements, model construction, project management, and design elements, and other areas of a project.

The technique described in this paper represents an exploration of the benefits to be derived from a combination of the rigour of structured system development methodologies (such as Yourdon structured analysis [1] or CommonKADS knowledge modeling approaches [2]) with the need for holistic analysis of problem domain (i.e. analysis that addresses organizational, social, and other human issues along with more technical aspects), explicitly addressing, and including, the freer-form, looser, conversational work necessary for a team to understand the modes they are building. This is enabled by harnessing and extending the hypertext functionality of a commercially available issue-based hypertext tool.

The technique is designed to facilitate a back-and-forth movement between structured and unstructured modeling and interpretive activities, and between formal and informal modes of team communication. The goal is to integrate these modes so as to achieve a high amount of synergy between structured and unstructured team activities. Informal communicative activities are crucial to the success of a project in both the short and long term. Project teams can benefit from explicit support of those activities, particularly in the linking of the results of those activities to the models that the team creates.

The technique was applied and refined in three projects over the course of a year, involving, besides the developer, 44 participants in various roles for various durations. Involvement ranged from half-day modeling/discussion sessions to full-scale modeling efforts lasting several months.

THE SOFTWARE ENVIRONMENT

QuestMap

QuestMap(TM) is an issue-based hypertext tool. Developed as an outgrowth of hypertext research at MCC in the 1980s, QuestMap provides a hypertext infrastructure, a rhetorical method for mapping discourse, and an approach to facilitating group discussions of complex issues [3, 4].

IBIS rhetorical structure

IBIS, or "Issue-Based Information System", is the rhetorical methodology that underlies QuestMap. IBIS involves making distinctions between Issues (questions), Positions (ideas about or possible answers to those questions), and Arguments (pros and cons to the positions), and making the appropriate semantic links between the icons, or "nodes", that represent these ideas. QuestMap allows the user to create free-form IBIS maps and lists.

The complexity of QuestMap's hypertext engine is kept hidden from the user, while providing a useful set of functions via an easy-to-use interface. In brief, the features of most importance here are the following:

the ability to create hyperlinks by copying a node from a map or list and pasting it into another (there is, in fact, no"copy" made, but rather the same node is now present in more than one "view")
a "Containing Views" feature that allows the display of a scrolling list showing all the views (maps or lists) that a particular node is "contained" in. The scrolling list is also a set of hyperlinks; users can click on any of the views listed and the system will take them to the node of interest in that view
each node contains a "Contents Window" that allows users to enter additional information about the node, including keywords that can be used in searches of the database. Contents windows are made visible by double-clicking on the node
a search engine that can display nodes containing certain keywords in scrolling lists, that can then be sorted according to various criteria. The lists are themselves sets of hyperlinks, as users can employ the "Containing Views" feature to locate the nodes of interest in context

MODELING TECHNIQUES

The technique described in this paper consists of overlays onto the basic IBIS structure provided by QuestMap. The overlays support both a structured modeling framework and the connecting of that framework to "normal" IBIS conversation mapping. The technique has two interrelated components: specialized maps and lists that are structured according to particular rules, and techniques for building and linking elements of maps and lists, such as hyperlinking strategies, node coding, templates, and labelling conventions.

Specialized map and list types

There are three types of specialized maps: models, which are structured representations of aspects of a problem domain; lists, which collect coded model elements in list form; and other map types such as project management overlays and general discussion maps. Each map type has several elements and simple rules governing their construction and use. Note that there are no software mechanisms to enforce model-building rules or provide consistency/coherency tests.

Models

Building models

The modeling technique makes use of IBIS conventions. The activity of model- building, and the models themselves, follows a question-and-answer format. The questions (generally speaking) are part of the defined templates for that model type, while the expected answers conform to the rules established for that model type. The questions and templates were derived from both structured modeling approaches and from experimentation and discussion with groups engaged in modeling. For example, questions about objects and their attributes were inspired by formal object-oriented analysis, such as Jacobson's methods [4] while questions about organizations and roles were originally based on elements of the CommonKADS Organization Model [5]. Questions about problems and opportunities were generated by both the analyst/facilitator in response to issues raised by the participating groups, and by members of the groups themselves.

Types of models

There are five types of structured model maps described here: Organization, Communication, Task/Process, Resource, and Problem/Opportunity models.

Organization models describe the social structure at work in a problem domain. They are intended to allow participants to gain understanding about the roles that different groups and individuals play in the problem domain
Communication models show the formal and informal communication between roles. They may also be used to represent the communication between human users and computer systems, or between systems and other systems
Task/Process Models represent the sequences and attributes of tasks and activities in the problem domain. They have several levels: a process or workflow level map will show the sequence of tasks, while a task-level map shows the attributes of a single task
Resource Models represent the attributes of physical resources used or consumed in the problem domain. There are many kinds of Resources: examples include systems, tools, paper forms, electronic parts, and vehicles. People are a special class of Resource; they are neither used nor consumed (at least, they are not modelled as such!)
Problem/Opportunity Models come closest to "conventional" IBIS maps. They are places where the issues that have come up in the course of modeling other aspects of the problem domain are discussed and analyzed by the project team following typical IBIS uses. Issues that arise in the course of reviewing and discussing Problem/Opportunity Models may also serve to inform subsequent model-building activities.

Much of the power and usefulness of this technique lies in the ability to link model elements themselves directly into unstructured discussions, so that the discussion and the structured model are two clicks away from each other. Multiple layers of activity and context are thus enabled and preserved. Participants can shift between "modeling" and "discussing" a particular aspect or issue many times in the course of a working session, without having to change tools and without losing the results of either activity.

Lists

Specialized lists combine QuestMap's search engine with the coding and labelling conventions described in this document. Lists can be used to produce documentation, to serve as menus or catalogs, and to show the progress of aspects of the modeling effort. The discussion below describes two types of specialized lists.

Open Issues lists As participants work through models or issues, they frequently encounter areas that require further research or work before the team can complete a model or resolve an issue. By placing an open issue code in the Contents window of the unresolved node or an adjoining node, an instant list of such open issues can be created or updated, no matter where in the database such nodes occur. This approach to issue tracking and management has the advantage that the context of issues is preserved, and available at any instant via the Containing Views hyperlink feature
Catalogues Up-to-date catalogues of different types of model elements can be produced simply and easily. Uses of this type of list include, for example, catalogues of all Roles, Tasks, Objects, or Communication models that participants have built to date. Catalogues can be used to print documentation of a modeling effort's results, to provide scrolling menus of model elements (these are especially useful during model- building sessions, when linking in attributes of model elements -- for example, they provide a simple way to locate all the Objects that might be involved in a particular Task), and as gauges of progress -- a "Node Count" feature provides the number of nodes in a particular list

Other map types

There are a wide variety of potentially useful specialized map types that could support this approach. The flexibility of the software tool and approach means that new types of useful views can be defined on the fly, with full interlinking capabilities to existing maps and lists. One type of specialized map that has proven useful are project management overlays. As with modeling activities, project management represents an area of project work where free-form, exploratory discussions alternate with and inform structured activities (and vice-versa). In the case of project management, those activities include defining schedules, deliverables, project tracking, status reporting, and so forth. Linking exploratory discussions about project management issues with the results of those discussions (e.g., linking discussions about the topic "what should our deliverables be?" with maps showing the agreed-on deliverables), as well as with artifacts of actual project work (e.g., models), is helpful in integrating the various strands of a project.

Specialized techniques

Hyperlinking strategies

Effective hyperlinking allows the creation of cross-references, multiple views, and a rich and robust model set. The more it is useful to understand an aspect of a problem domain in multiple dimensions, the more it is useful to create hyperlinks. A node that has a certain meaning in a specialized map or list can play different roles in other maps or lists. Hyperlinking shows, reinforces, and manages this multidimensionality of meanings. The other techniques discussed in this document are in support of, and achieve their true leverage through, these hyperlinking strategies.

An example: In modeling a Role named Technician, the team has identified "Service Order", one of the information objects that the Role comes into contact with, as one of a Technician's attributes. Service Order is itself modelled on an Object Model map, with its own attributes, including a Problem/Opportunity attribute titled "Not implemented correctly". Service Order also appears as an object attribute on a Task Model map for a Task named "Installation". The object also appears as an entry in a Catalogue of Objects. Finally, the team has identified Service Order as one of several objects for which there are "Implementation Problems" (in a Problem/Opportunity Model map).

The node named "Service Order" appears in all four maps as the result of Copy-Paste actions (i.e., the team has copied the node and pasted it in the each map shown here. When a user selects the "Containing Views" option while pointing one of the appearances of the Service Order node, the software will tell them all the other places that Service Order appears.

Hyperlinking in practice

The general procedure for hyperlinking is to create a link (i.e., paste an existing node into one or more additional maps) whenever there is a relationship that the team believes is or may become significant or meaningful to understanding the problem domain, managing the project, or communicating effectively.

This kind of hyperlinking can, in itself, produce new understanding. By continually asking the question "Where (else) should we link this element?" the team, in effect, is asking "Where is this piece of information significant?" Thus, the team is continually interpreting the significance of individual model elements, relationships between elements, and relationship of the models to the goals of the project.

The extent and volume of hyperlinking that a team undertakes should be driven by the project's goals and the time available for modeling, along with other factors. There are always trade-offs between model extent and model usability.

Node coding

Node coding involves placing codes in the Detail field of the Contents window of particular nodes. The codes enable searches, cross-references and the on-the-fly creation of specialized maps and lists without the manual work of assembling them node-by-node. Because subsequent searches will find coded nodes wherever in the database they may lie, teams effectively "seed" other model types and catalogues by entering a code whenever they create a node of one of the specialized types.

Labelling conventions

To ensure that entries on maps, lists, catalogues, and hyperlinks support effective browsing, searching, and perusal, a number of labelling conventions should be adhered to. These conventions apply to some node and map labels and descriptions. For example, maps containing models of individual Roles should be labelled with the name of the Role followed by the word "(Role)" in parentheses. Thus subsequent Containing Views selections and Catalogues will be easier to read and understand.

Templates

Templates are a way to facilitate the creation of model maps or other specialized maps that follow a structured format. The formats consist of a set of questions that are asked of model elements. These questions can be saved in templates and brought in to new model maps. For instance, the process of modeling a Role can be jump-started by importing the Role Model template.

CONCLUSION

Teams charged with designing effective business process or technology interventions need access to all the rich detail about their problem domain without being overwhelmed by its complexity. They gain their understanding of the "big picture" through understanding the meaning of the elements of the domain, at many levels of granularity. Such meaning is not inherent in the elements themselves; it must be produced through collaborative analysis and conversation. Ideally, tools could support each mode (modeling and conversation) with full hyperlinking capabilities as well as a rich set of representational possibilities. Because it was based on off-the-shelf hypertext technology, the technique described in this paper, of necessity, relied on a limited representational palette and other restrictions in representational and hyperlinking capabilities. Future efforts could expand on either side of the equation to provide more powerful toolsets for team analysis.

Citations

[1] E. Yourdon, Modern Structured Analysis, Englewood Cliffs: Prentice Hall, 1989.

[2] B.. Wielinga, A. Schreiber, J. Breuker, KADS: A Modeling Approach to Knowledge Engineering, KADS-II Consortium (ESPRIT Project P5248 KADS-II), Document Identifier KADS-II/T1.1/PP/UvA/008/1.0.

[3]. E. J. Conklin, M. Begeman, gIBIS: A Tool for Exploratory Policy Discussion, in Proceedings of CSCW '88, Portland, Oregon, September 1988, and ACM Transactions on Office Information Systems, October 1988.

[4]. K. Yakemovich, E. J. Conklin, Report on a Development Project Use of an Issue-Based Information System, in Proceedings of the 1990 Conference on Computer-Supported Cooperative Work, ACM 1990.

[5]. I. Jacobson, M. Ericsson, A. Jacobson, The Object Advantage : Business Process Reengineering with Object Technology, Workingham: Addison- Wesley 1994.

[6] R. de Hoog, B. Benus, C. Metselaar, M. Vogler, Applying the Common KADS Organization Model, KADS-II Consortium (ESPRIT Project P5248 KADS-II, Document Identifier KADS-II/T M6/DM6.1

This paper appears in the Proceedings of the Second International Workshop on Incorporating Hypertext Functionality into Software Systems, held in conjunction with the ACM Hypertext '96 conference, Washington, U.S.A.