Citation
Hypertext and decision types

Material Information

Title:
Hypertext and decision types a framework for designing a group decision support system (GDSS) with an empirical decision type example
Alternate title:
Framework for designing a group decision support system GDSS with an empirical decision type example
Creator:
Pongonis, Robert George
Publication Date:
Language:
English
Physical Description:
vii, 84 leaves : illustrations ; 29 cm

Subjects

Subjects / Keywords:
Hypertext systems ( lcsh )
Group decision making ( lcsh )
Group decision making ( fast )
Hypertext systems ( fast )
Genre:
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Bibliography:
Includes bibliographical references.
General Note:
Submitted in partial fulfillment of the requirements for the degree, Master of Science, [College of Business Administration] Management Science/Information Systems.
Statement of Responsibility:
by Robert George Pongonis.

Record Information

Source Institution:
|University of Colorado Denver
Holding Location:
|Auraria Library
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
28528498 ( OCLC )
ocm28528498
Classification:
LD1190.B85 1992m .P66 ( lcc )

Full Text
HYPERTEXT AND DECISION TYPES
/
A Framework for Designing a
Group Decision Support System (GDSS)
with an Empirical Decision Type Example
by
Robert George Pongonis
B. A., University of Connecticut, 1974
M. B. A., University of Colorado (Denver), 1988
A thesis submitted to the
Faculty of the Graduate School of Business of the
University of Colorado at Denver
in partial fulfillment
of the requirements for the degree of
Master of Science
Management Science / Information Systems
1992


This thesis for the Master of Science
degree by
Robert George Pongonis
has been approved for the
School of
Business
by
Date


Pongonis, Robert George (M. S., Management Science/
Information Systems)
Hypertext and Decision Types, A Framework for Designing
a Group Decision Support System (GDSS) with an
Empirical Decision Type Example
Thesis directed by Associate Professor Feng-Yang Kuo
ABSTRACT
This thesis presents a framework for assisting
information system designers in the development of Group
Decision Support Systems (GDSS) using the Hypertext
paradigm. It accomplishes this goal by using the results
of the literature research to establish the requirements
for such systems and a conceptual model to characterize
current and future systems. The conceptual model is
based on the classification scheme of decision types.
This scheme characterizes decisions in terms of the
degree of structuredness used to make the decision and
the initial availability of information. The thesis
targets the group decision making problems characterized
by a high degree of structuredness in the procedure and
little initial information. In these problems, a
iii


decision is reached by the methodical implementation of
the procedure to gather and compile pertinent
information.
To provide evidence of the utility of this framework
a prototype of a specific application is presented using
the Hypertext paradigm. The specific application is the
United States Air Force regulation for the Source
Selection Process for Major Systems Acquisition (AFR 70-
15) .
The results of the development of the prototype
provide evidence that the framework and Hypertext are
useful in developing a GDSS. Also, the effort of
developing the prototype reveal a GDSS tool architecture
that could be used by decision process designers to
develop similar group decision support systems.
This abstract accurately represents the content of
the candidate's thesis. I recommend its publication.
Signed]
Faculty member in charge of thesis
iv


CONTENTS
CHAPTER I PAGE
INTRODUCTION ........................................ 1
Overview of the Research .......................... 4
CHAPTER II
GROUP DECISION MAKING - The Problem Domain ... 8
The Conceptual Model - Decision Types 8
Process Methodology .............................. 14
Substantive.................................... 14
Procedural...................................... 15
Description..................................... 16
Process Management ............................... 16
Documentation................................. 18
Involvement..................................... 19
The Group's Role.................................. 20
Comprehensiveness .............................. 21
Objectivity................................. 22
Individual Participation ......................... 23
Preferences..................................... 23
Usability....................................... 24
Summary........................................... 25
v


CHAPTER III
PAGE
HYPERTEXT The Solution Domain .................... 26
Hypertext Features ............................... 28
Nodes........................................... 28
Links........................................... 30
Overviews.................................... 32
Versioning................................... 32
Guided Tours ................................ 33
Collaboration ............................... 34
Distribution and Openness . . ............ 34
Hierarchies................................... 35
Search/Query ................................ 36
Storage...................................... 3 6
Security and Integrity ...................... 37
Summary........................................ 37
CHAPTER IV
A SPECIFIC SYSTEM IMPLEMENTATION................. . 39
AFR 70-15 as a Decision Type................... 4 3
An Overview of the System's Entities.............. 46
The System Prototype ............................. 51
Overview The Main Screen..................... 58
A Guided Tour AFR 70-15 Document........... 60
Approval/Review Versioning ............. 60
Collaboration Lessons Learned ............. 60
vi


PAGE
Security The Organization..................... 67
Distribution and Openness The Schedule . 67
CHAPTER V
CONCLUSIONS......................................... 73
A GDSS Tool Architecture.......................... 76
Overview Creation .............................. 77
Information Layout...........'............... 77
Link Manager................................... 78
Function Manager ............................... 78
Security Manager ............................... 79
Additional Research............................ . 79
BIBLIOGRAPHY ......................................... 81
vii


CHAPTER I
INTRODUCTION
Office automation has changed the American work
place since its introduction in the 1970s. It has
resulted in a great increase in personal productivity
through the use of tools such as 1-2-3 and Dbase.
Workers are now demanding computer-based systems that
allow them to freely exchange information with their
peers and that facilitate the process of working together
on tasks. This demand is pushing system designers to
examine how groups work and to develop automated ways to
support them.
Group decision making is an important area of study
because it provides advantages to organizations in making
effective decisions yet it has inherent problems. On the
positive side, it provides a large source of information
and facilitates tasks such as the summarization of issues
and the evaluation of alternatives [28] [19]. However,
it can be costly, difficult to control and prone to
politics and conflict. These problems adversely affect
the outcome and they are considered the primary cause for
many disastrous decisions [14] [28]. To remedy this,
some researchers have been examining group decision
1


support systems (GDSS) as a means to enhance the benefits
of group decision making while mitigating its problems.
One form of GDSS supports face-to-face meetings in
complex collaborative efforts [37] [40]. These systems
improve the group's task performance and reduce
communication problems [2]. Information gathering,
organization and processing are automated and structured.
Communication is improved by having automated feedback on
the group's social dynamics [41]. This helps the group
members quickly recognize interactions that hinder a
group's progress.
Another form of GDSS is the distributed GDSS. These
are designed to support the collection and organization
of information that is needed in the decisioning process.
Recently, systems such as SIBYL [17] and gIBIS [6] were
introduced to support these functions for group
mediation. These systems organize the information in a
decision problem around specific rhetorical models.
These systems are limited, however, in that they do not
support the complete decision process which includes the
compilation of information into documents [34]. These
documents are necessary because they explain the
information regarding the decision to those involved in
later stages of the process or in the implementation of
the decision.
2


This research examines the suitability of the
Hypertext paradigm for meeting the requirements of the
group decision process. It has been proposed that
successful Hypertext DSS applications may someday be
characterized in a decision problem versus system
suitability framework [21]. In such a framework, a
system would be identified as supporting a decision
problem characterized by a classification scheme. This
research contributes to this goal by utilizing the
concept of the decision type [28]. A decision type is
characterized by the degree of structuredness in the
decision procedure and the initial availability of
information. This characterization provides a means to
distinguish between the information and procedural
requirements met by systems like gIBIS and SIBYL, and the
prototyped system examined in this study.
In addition to the decision type, the total
requirements for group decision making must also be
considered. Requirements related to process management
and process methodology, for example, include aspects
that are common to all decision types. These
requirements must be correlated with the features of the
candidate system (in this case, Hypertext) to determine
suitability. An understanding of both the decision
making process and the candidate system's features will
3


allow designers to provide useful, comprehensive
solutions.
To provide evidence of the effectiveness of this
approach, a heuristic prototype [36] was developed for an
existing manual system. This system is the United States
Air Force source selection process for major systems
acquisition (AFR 70-15).
The thesis work reveals a possible design for a GDSS
tool. This tool could be used by a GDSS designer to
create a decision process for use by participants in a
distributed environment. It will provide decision
process designers with an effective means to deal with
the complexities of designing a group decision process.
Overview of the Research
To effectively address the proposition of this
thesis, two problems have to be resolved. First, it is
necessary to understand group decision making
requirements. Literature in decision making and group
work shows GDSS is supported by many disciplines such as
management, psychology, behavior and operations research.
In practice, theories and principles from these areas are
applied toward unique decision making situations.
Because of the complexity and variety of the decision
making situations, process designers must offer tailor
4


made solutions. This makes it vary difficult to settle
on a single specific approach for designing a GDSS.
Attempts are being made to develop general
guidelines for designers [22] but, at present, there are
none. Therefore, this research synthesizes information
about group decision making to establish the necessary
requirements for a GDSS. This synthesis provides the
designer with a conceptual framework so that specific
architectural features for a GDSS can be considered.
The second problem that needs to be resolved is to
clarify the nature of Hypertext. Hypertext is not
supported by the clear theoretical foundations that
characterize other subjects, such as a relational data
base design. Researchers have not agreed on a definition
of Hypertext [33] [10]. It is difficult to use a
theoretical approach to evaluate it. This problem is
resolved by adapting the results of an investigation that
summarized the features of existing Hypertext systems
[12].
The resolution of these two problems permits an
analytical correlation of the problem domain's
requirements (Group Decision Making) with the solution
domain's features (Hypertext). Figure 1 summarizes the
research process and also depicts the organization of
this thesis. Steps 1 and 2 are concerned with defining
5


Process followed in considering Hypertext as
a system solution for Group Decision Making.
Figure 1
6


the requirement characteristics for the problem domain
and possible design solutions. The second part of this
effort (Steps 3 and 4) analyzes how the features of
Hypertext can be utilized to support the requirement
characteristics. These first four steps are supported by
the literature research.
The last part (Steps 5-7) is concerned with
developing a prototype of a specific application to
demonstrate the usefulness of the framework and the,
utility of the Hypertext paradigm as a system solution.
Finally, conclusions (Step 8) are drawn from this
effort. Two main conclusions are reached. First, this
framework provides designers with a theoretical
perspective of the requirements for a GDSS and solutions
available using the Hypertext paradigm. Secondly, the
efforts of constructing the prototype reveals a GDSS tool
architecture for decision process designers.
7


CHAPTER II
GROUP DECISION MAKING The Problem Domain
Research and discussion of group decision making
tends to fall into four general categories: process
methodology, process management, role of the group, and
individual participation. Specific requirements
identified from this research and associated with these
areas are shown in Table 1.
Because decision problems have different
characteristics [20] [19], it is necessary to use a
conceptual model that characterizes the decision problem
domain in order to make distinctions in a system design.
This allows a particular system design to be related to
the decision problem(s) that it addresses.
The Conceptual Model Decision Types
Terms used to describe differences in decision
problems include complexity, uncertainty, conflict, and
ambiguity. These terms are not easily transferable to a
system's design. However, the decision type
classification scheme [28] used here deals with the
parameters of procedure and information which are
8


Group Decision Making Problem Domain
Issue Areas Requirements
Process Methodologies Substantive Procedural Description
Process Management Documentation Involvement
Groups' Role Objectivity Comprehensiveness
Individual Participation Preferences Usability
Table 1
9


routinely used by systems designers. System designers
are concerned with the nature of the information that
will be a part of a system and the procedures that
process that information. Therefore, if a decision
problem can be understood in these terms, the problem can
be better understood by the designer.
Figure 2 illustrates the decision type
classification scheme. Two parameters are used to
characterize decisions: the initial availability of
information (rich or poor) and the extent of structure in
the decision making procedure (well structured or poorly
structured). Based on these two parameters, decisions
can be classified into four types: representation,
information, empirical, and search. This classification
allows us to understand the dominant activities for
making a decision of a particular type. These dominant
activities can then be used to understand the
requirements for a GDSS.
Representational decisions are both rich in
information and have a well structured procedure
necessary for making the decision. These decisions
primarily use mathematical models and can be supported
by tools such as spreadsheets, linear programming
modules, or command line driven model generators. The
10


Types of Decisions.
Nature of Information
Veil
Structured
Procedure
Poorly
Structured
Figure 2 [from Nutt 1989]
Rich Poor
Representational Decisions Empirical Decisions
Information Decisions Search Decisions
11


results obtained from the use of these tools with the
available information form the basis for the decision.
Information decisions have poor procedural structure but
do have adequate information to reach the decision. The
dominant activity in these decisions is the synthesis of
the available information through the process of
negotiation [28]. These decisions can be approached by
first developing complete positional arguments. These
positions can be established in detail by creating
subgroups whose members hold common perspectives, views
or possess similar cognitive characteristics [19]. These
groups identify the strongest arguments for their
position, which then can be used as a basis for
negotiating a solution. SIBYL [17] and gIBIS [6] are
systems that address the dominant activity of this
decision type. They are designed to organize the
relevant information around issues (gIBIS) or goals
(SIBYL). The decision is obtained by resolving each
issue or goal through a rational process of argumentation
or formal discussion.
Empirical decisions have a highly structured
procedure but lack the information to make a decision.
These decisions use a solicitation process. These
processes require formulating a solicitation, which
defines the problem, so that specific solutions can be
12


proposed. Ideally, the proposed solutions are evaluated
with guidelines established during the creation of the
solicitation. These guidelines define how the proposed
solutions will be compiled and evaluated to reach a
decision. Both the development of a solicitation and the
means of compiling the results can be described as
authoring. Authoring involves a process of search and
synthesis. Information is gathered and associations are
made to try to form a structure or outline. Once the
outline has been established the information is expanded
into a coherent and intelligible document.
Search decisions have both poor information
available and a poorly structured procedure. Prime
examples are strategic decisions. These decisions
require gathering intelligence (information) and then
assigning meaning to it in order to decide on a response.
The SAST [19] method is an example of a decision process
used in this type of situation.
This discussion points to two distinct activities
inherent in any decision process: discussion, which is
necessary to synthesize the information, and authoring,
which is necessary to support the formal procedure. The
former is exemplified by the information decision types
that are supported by systems such as SIBYL and gIBIS and
the latter is most evident in the empirical decisions
13


that will be prototyped in this research. The latter is
specifically concerned with the compilation of the
information into documents. It includes any prerequisite
tasks that are required by the process such as,
generating lists, scoring options and commenting
intermediate results.
Process Methodology
Substantive. Procedural and Description
A decision process methodology specifies how the
decision process will proceed and what information will
be considered in the process. It can be decomposed into
a substantive element and a procedural element. These
two elements are tied together by a description element.
Together, these three elements define the basic
requirements that must be met by any GDSS.
Substantive
The substantive requirements can be deduced from the
application of the conceptual model to a specific
decision process. In a process that is designed to
support discussion, there must be a way to store and
access the concise information that occurs in this
activity. The gIBIS [6] designers found that a RDBMS was
useful. However, it was inadequate as a complete
14


decision process solution because it did not provide
access to items such as freeform text or graphics needed
to support the issues [also see 10]. Some Hypertext
systems such as KMS [1] can support these additional
items. KMS has been proposed as a general solution to
the problem of organizational information management.
The basic storage element of this system is called a
frame, which can contain both text and graphics.
Individual frames can be used for handling the concise
information and many frames can be linked together so
that an entire document can be stored and reviewed.
Procedural
The procedural requirements for a decision process
are characterized first by the degree of structuredness
in the sequence of the steps and tasks. A highly
structured procedure will have a clearly delineated
sequence with little provision for diversion and
iteration. If discussion is not considered, the process
would appear as a simple sequence of authoring activities
that build upon one another. For example, a set of goals
will be followed by a list of alternatives, which then
must be clarified with a list of assumptions, etc.
Secondly, the requirements are characterized by the
level of detail in the definition of the type and form of
15


the information that will be produced. Templates that
outline the form of the information and examples of the
information are used to illustrate these requirements.
Whereas the first element spans the entire decision
process, the detailing of the information is an authoring
activity requirement.
Description
Establishing a group process is a means of
organizing human activity through standardization [24].
Standardization is supported by developing formal written
documentation of the process. This documentation
explains the individuals' roles and responsibilities and
the activities of the process. Graphics, such as process
diagrams (Figure 3), are used to help explain the
process. Therefore, access to a written description of
the process (that can include diagrams) is a system
requirement.
Process Management
Documentation and Involvement
The process management requirements accomplish two
goals: preservation of the information resource and
efficient involvement of the participants. Information
preservation is accomplished through documentation.
16


The Decision Process
[From Nutt3 1989]
Figure 3
17


Efficient involvement is achieved by providing sufficient
time for the participants to accomplish their tasks
without wasting individuals' time in protracted
interactions or solitary tasks.
Documentation
Process documentation benefits an organization by
providing a reference source for future decision making
[34]. A lack of documentation is the source of many
system maintenance problems. Also, the accessibility of
information determines its utility. If a laborious
search is necessary to ferret out information and its
relationships, the usefulness of the documentation is
lessened. Therefore, a system must document the process
and provide a means to easily retrieve information.
Second, documentation supports the required learning
step (see Figure 3) [28] [19]. This step reviews the
history of the decision problem and the process so that
improvements can be made. In practice, the learning
process is often delayed or forgotten. This can result
in the loss of information required for follow-up
decisions. Also, individuals may withhold information
about a decision's failure to obscure what went wrong.
These problems can be mitigated if information about the
18


decision is collected during the process and made
available for later review.
The documentation requirement for discussion differs
from the documentation requirement for authoring.
Documenting a discussion activity requires the use of a
rhetorical model to place the information within the
appropriate context. Issues, arguments, etc. must be
contextually related so that the discussion can be
understood. This must be coupled with features that
permit the discussion information to be quickly located
and summarized. Queries, graphical views, and itemized
statistics are examples of features that are useful in
understanding a discussion [6].
Documenting the authoring activity requires the
retention of the document versions and the collaborative
communication that formed the review and approval process
[34]. Examining the content of the versions alone will
not give a complete understanding of why another version
was needed.
Involvement
Group decision making can be costly because it is
personnel intensive. Individuals are removed from their
normal productive activities and are dedicated to
supporting the decision making group. This occurs even
19


though some of the tasks performed during the group
process are distinctly individualized, such as writing
down issues, scoring options, and presenting concerns
without debate [19]. It may be unnecessary for the group
to be physically assembled together throughout the entire
decision making process. However, research shows that
exploring issues before a meeting helps groups become
more focused and develop a more productive agenda [34],
Therefore, the basic requirement for a GDSS is to
minimize the time that a group must be assembled yet
still provide the means for meaningful communication
before, during, and after the process.
The Group 1s Role
Comprehensiveness and Objectivity
Comprehensiveness and objectivity are two
requirements that define the information that the process
will address and the extent of individuals involvement in
the decision process. The latter may be considered as
the assignment of roles in the decision process.
Whereas, in some instances equal and total involvement
may be prescribed in the decision process, other times
individuals will play only a selected part in the
decision process.
20


Comprehensiveness
According to Webster's New Collegiate Dictionary
[The G. & C. Merriam Co., 1981], comprehensive means
"covering completely or broadly." A dominant theme in
much of the group decision making literature is how
groups expand the scope and depth of the required
knowledge in decisioning problems [28], [14], [19]. This
knowledge expansion requires a greater variety of
associated information to articulate the knowledge. This
information can occur in many forms, such as quantitative
measures, qualitative descriptions or graphical images.
Therefore, the comprehensive requirement creates a need
for flexibility to deal with a large volume and variety
of information.
However, some processes can be designed to narrowly
define the nature and type of information that will be
considered in the process. For example, a group may
consider the technical merits of acquiring a new system
without considering any ancillary issues, such as costs
or social concerns. This ensures that the group will not
become bogged down in areas that do not support their
purpose. Hence, their decision is limited in the extent
of its comprehensiveness.
21


Objectivity
Another dominant theme found in the literature is
how a group functions to provide an objective, unbiased
decision. This requires that issues of the decision
problem are clearly articulated so that group members can
evaluate them rationally [32] [16] [19]. However,
absolute objectivity is not necessarily a requirement.
In some instances, authoritarian influence is required to
handle problems with overriding constraints.
One group process that supports this concept is the
Kiva process. It is named after a meeting facility that
was used for the decision process of the North American
Hopi Indians. The process divides the group into several
ranks of authority. It begins and ends with the highest
ranking group, which retains the ultimate authority for
making the decision. Each rank takes turns discussing
the issues among their own members but the entire group
is permitted to listen. Hence, this process satisfies
the comprehensiveness requirement to the extent that all
views are included. However, it risks being unobjective
because it retains a single responsible body for the
decision. Thus, the final decision can be biased by the
views of the highest rank.
These two requirements point out the need for a
decision process to take into account the exact nature of
22


comprehensiveness and objectivity. This includes how the
group members will be organized, the structure of the
participation process and the content of the information
that will be considered.
Individual Participation
Preferences and Usability
Preferences and usability are requirements that have
been derived from the research in designing computer
systems for supporting group work. Both of these relate
to the concerns that designers must have on how a new
system will impact workers.
Preferences
The literature on computer support for group work
shows that individual participation can be a concern.
Individuals may have developed preferences for specific
tools [13] [11] such as spreadsheets, data base
management systems, and wordprocessors that can be used
in the decision making process. Not taking these
preferences into account can hamper participant
effectiveness. Participants who lack the motivation or
ability to learn a new tool will not participate fully.
23


Usability
It is unlikely that the individuals selected for the
decision making process will have the prerequisite
knowledge needed to operate the entire computer system.
Therefore, an overriding requirement for general user
acceptance exists.
Research has shown that Hypertext exhibits qualities
that make it easy to use [27]. These qualities include
ease of learning and remembering, efficiency, few errors,
and the pleasantness of the using experience. However,
these are generalized qualities of all Hypertext
applications and are affected by individual differences
and task requirements. Observations made in the
utilization of gIBIS showed very unequaled participation
among users [6]. Exactly why this occurs is unknown but
it is similar to some individuals choosing not to
participate in face-to-face meetings. Therefore, a lack
of usage cannot always be attributed to usability.
A caveat to the concept of usability of a Hypertext
system is that specific requirements depend on the nature
of the task. Positive responses to a system's usability
will probably increase as features are implemented to
address a particular user concern. There can be some
incongruence between a system's potential usability and
the extent of features currently available [33] [12].
24


Summary
This chapter summarizes research on group decision
making. The conceptual model (Figure 2) establishes a
way to relate requirements derived from this research to
existing systems. The fulfillment of the requirements
(Table 1) will determine the success or failure of a
proposed solution to the group decision making problem.
For the process methodology requirement, the solution
must offer features to handle the different types of
information used in the process, a feature that supports
the structured procedural element and a description that
guides the participants. The process management
requirement establishes the need for involving the
participants efficiently and ensuring that the
information is retained in a useful manner. The
requirements of the group's role establishes both a need
for assigning roles in the process and a need for dealing
with the variety of information that the participants
will bring. Finally, the needs of the individual must be
considered because without the individual's support, no
decision making process can be successful.
In the next chapter the specific architectural
features of Hypertext will be examined for their utility
in supporting these requirements.
25


CHAPTER III
HYPERTEXT The Solution Domain
Hypertext has been proposed as a solution to a wide
variety of difficult information management problems [1]
[9] [18]. Hypertext can be described as a series of
information nodes that are linked together with pointers
(also called buttons or triggers). The links are
embedded or associated with the information that is
contained within the node and they are selected with a
pointing device (a mouse for example) or the cursor.
Initially, Hypertext systems were text based and the
information associated with the link was a segment of
text. Selecting a segment would present the user with
another node of information. Currently, other objects,
such as graphics can be placed on the node to represent a
link. Also, special objects or labelled links can be
used to initialize other programs.
The use of these relatively simple concepts has
resulted in the development of many useful systems [1]
[6] [12] [18]. This research examines the architectural
features that have been previously employed by these
successful Hypertext systems [12] [33] [31]. Table 2
lists the features, along with the decision making
requirements that they support.
26


Feature Requirements
Nodes Substantive, Procedural, C0mpreh.ensive2.ess
Links Procedural, Documentation
Overviews Description, Documentation
Versioning Documentaion
Guided Tour Description
Collaboration Substantive, Documentation
User Interface Usability
Distribution & Openness Prefoenoes, Involvement
Hierarchies Procedural
Search & Query Documentation
Storage Substantive
Security Objectivity
Table 2 Correlation between Hypertext features and
requirement characteristics.
27


Hypertext Features
Nodes
Nodes (along with links) are one of the unique
features of the Hypertext paradigm. There is no standard
means of implementing a node. Some Hypertext systems are
designed to use text files as nodes that have pointers
embedded into the text. These pointers identify the
location of a link within the file and some information
describing the address of the node to which it is linked.
For example, special characters may be inserted around a
word or phrase that identifies this information as a
link. The Hypertext system reads this file and uses the
embedded characters to identify the link to the user.
When the user selects this link, the system moves to the
node identified by the address.
Another approach uses a cardfile metaphor. In this
approach a flat file is used to store the information in
records that are called cards. The visual presentation
of the card is similar to that of a database form with
fields located on the card to view the information
contained in the records. Additionally, links (or
buttons) are defined for the card. The card can be
viewed as a series of overlays [27, pg. 97] of fields,
buttons and background. The important consideration in
using the cardfile approach is whether the information
28


can be broken down into records. If not, then every
change of field definition or the location of buttons
will require the use of a new and different cardfile.
Three GDSS requirements are supported by the
Hypertext node. The substantive requirements of
discussion and authoring are supported by the flexibility
of a node to handle different types of information. That
is, the concise packets of information found in
discussion can be expressed in a single node, while the
longer text and graphic elements of authoring can be
compiled into a series of linked nodes. All of these may
be linked together to form the total framework of
information in the decision process. For example,
concise packets of information in the form of annotations
or comments may be linked to other annotations. These
will be linked to the documents and in this way the
context of the information is preserved.
The procedural requirement can be supported by using
the nodes as templates for creating the documents. A
document can be organized in sequence as in paper form,
broken down hierarchically and expressed in an outline,
or organized in a network fashion that has a special
meaning to the application. When using a cardfile
approach, special consideration must be made for how the
29


information will be reorganized into the cards or frames
[18].
Hypertext also satisfies the comprehensiveness
requirement with its ability to present various types of
information through a node. Text, charts, pictures and
quantitative data, can all be required in a decision
process and can all be accessed through a Hypertext node.
Links
Links are the other unique and essential element of
the Hypertext paradigm. They are associated with a node
at a point of anchoring, which is sometimes
metaphorically described as a button. They can be used
to satisfy the procedural requirement of the decision
process by linking together the information produced in
each stage of the process. Therefore, a user that is
working on one document can have access to another
document produced by a predecessor in the process.
Links can also capture the evolution of information
associations created in a procedurally weak decision
process (search and information) and in collaboration.
These associations establish the context element of the
information and support the documentation requirement.
The aforementioned require explicit linking whereby
the designer or user has specifically assigned a link
30


from one node to another. Linking can also be made
implicitly by locating a node based on the information
content of the button [27]. For example, selecting a
word or phrase within a document may invoke a search for
information about that word or phrase. A special
application using implicit linking can support
authoritative arguments [19]. These arguments, which are
statements of presumed fact made by authoritarian
figures, often go untested. A statement such as our
competitor's sales increased by 30% last year therefore
we should ..." could be better understood and
subsequently challenged or supported if the statement
could be linked to an expanded contextual information
set. Since inclusion of this statement may be
unexpected, or the person making the assertion may not be
motivated to provide supporting evidence, the link must
be constructed dynamically. This presumes that the
system has a certain degree of intelligence to parse the
statement and determine where to search for the
supporting data. Alternatively, an interested
participant could perform a search on key words taken
from the statement.
31


Overviews
In working with large information networks, users
can become disoriented or lost [39] [33]. One solution
to this problem is the utilization of overviews or
browsers. These are essentially high level views of the
information accessible from the current node. They can
be static and impose a particular structure and
organization upon the information network or dynamic and
used to summarize the organization of the information as
it is compiled.
These overviews support the description of the
process [12] as an outline or process diagram and they
support the documentation requirement [34] whereby an
individual can use the overview to easily retrieve
information. Also, in the case where discussion is
supported by the system, the overview can outline the
organization of information in the rhetorical model. In
this way, a user can recognize where major discussion
areas were [6].
Versioning
Versioning supports both the procedural requirement
and the requirement for documentation. An aspect of the
procedural requirement is the iterative process found in
decision making [28] [19]. Information is replaced or
32


enriched as new information is uncovered through the
discussion and additional constraints may be imposed by
those who review and approve the intermediate results.
The association between versions of information sets is
supported by Hypertext's linking capability.
Documentation is required to support the
understanding of the evolution of the decision. Both the
content and the context in which the information was
created must be retained. This important function of
retaining the context of the information is provided by
linking the collaboration or discussion nodes to nodes
containing the information to which they refer.
Guided Tours
Guided tours are specially designed forms of
navigation through the information in a Hypertext system.
They are used for teaching or as a system tutorial [33].
A special set of nodes are created and linked to relevant
information that is contained in the system. Following
these nodes and examining the references with which they
are linked, provides an introduction to the system. This
feature helps satisfy the requirement for a process
description.
33


Collaboration
Collaboration is one of the requirements for group
authoring. Nodes of information connected to items such
as annotations, comments, and messages are essential to
the substantive requirement of authoring and also add
context to the information. The context is required for
the process documentation.
Distribution and Openness
This research is concerned with the ability of a
group to perform functions at different locations
(distribution) and the ability of users to perform these
functions with tools of their choice (openness). The
first ability addresses the requirement of involvement
and the second ability addresses the requirement of
preferences.
Hypertext has these abilities due to its means of
data management. Hypertext primarily uses operating
system capabilities to achieve integration of the
information (data) [21]. Therefore, if the node has been
appropriately defined to handle the information, all that
is required is a system call to identify the file. This
means that the file can be located on any logical device
on a network. To achieve the desired openness requires
that the tool being employed output a format that is
34


acceptable to the node. Most commercial tools available
have some export features that output 1-2-3, DBase, or
ASCII compatible files. If, however, the information
cannot be output in an acceptable format then it will be
necessary to incorporate an information transfer program
to read and reformat the data for the node.
Hierarchies
Hypertext supports associations based on any type of
network. Hierarchies exist in a large number of
information models such as outlines, functional
decomposition and work breakdown structures.
Hypertext offers effective ways to organize and
traverse hierarchical information. From any node, the
selection of a button that represents a parent or child
to that node is accomplished intuitively if the button is
well designed.
In the decision making context, both the breakdown
of large problems into smaller more manageable ones, and
the relationship between goals, alternatives, objectives,
and criteria may be developed as hierarchies [21]. Also,
utilizing rhetorical models for conversing about issues
can be conveyed by using a hierarchical organization
[32]. These are issues of the procedural requirements.
35


Search/Ouerv
This feature may be considered either as the
implicit linking mechanism previously mentioned or as a
means of accessing external references or data bases.
It is analogous to many of the file management utilities
that exist in commercial software, which allow searching
for specific text strings to help locate a particular
file.
An interesting utility to support the requirement
for documentation can be envisioned that would assist in
auditing the process. It might be important determine
whether a particular subject matter was adequately
treated in the process. By searching the system with
specific character strings, any references could be
quickly identified.
Storage
The two types of storage found in Hypertext systems
are standard file and the DBMS model (relational or
flatfile). However, there is no reason to make these
mutually exclusive or not allow for the possibility of
other schemas, such as a hierarchical model. In most
decision problems, we might consider the utilization of
many storage schemes and formats. It has already been
described how the relational model was used in gIBIS and
36


the file requirements for authoring larger documents.
Therefore, this feature supports the specific substantive
requirements for a decision support system.
Security and Integrity
Security and integrity in a Hypertext system can be
implemented by the concepts of conditional links [31] and
attributed links. In the former, links are activated (a
traverse occurs) when the user's access privileges are
acceptable. In the latter (which is most closely related
to a link type [10]) the link is activated but the
functions that are available at the new node will depend
upon the user privileges. For example, a user that has
only browsing privileges will not be permitted to alter a
document.
These special linking capabilities can be used to
support the objectivity requirement. The assignment of
roles in a decision process can be used to selectively
tailor the decision process such as in the Kiva process.
Summary
This discussion has established a correlation
between the requirements for group decision making and
the features of Hypertext. Whether or not the
correlations are sufficiently strong enough to support
37


the premises of this thesis will depend on whether the
implementation is accepted. This requires examining the
results of implementing a specific application.
38


CHAPTER IV
A SPECIFIC SYSTEM IMPLEMENTATION
The application selected to illustrate the premises
of this thesis is Air Force Regulation 70-15, Formal
Source Selection for Major Acquisitions. This procedural
regulation describes in varying detail the entities,
activities, and information required for the source
selection process. It was chosen because of its explicit
description of the process and richness of features
relevant to the group decision making process. Most of
the decision process topics previously discussed can be
directly correlated to this procedure.
The following brief explanation of the process is
intended to provide the reader with an understanding of
the major stages and events of the process, and the
entities associated with it. The full text of the
regulation has been incorporated into the prototype and
may be accessed from the main screen.
The source selection process begins with the
convening of a Business Strategy Panel (BSP). This panel
performs a function analogous to the exploration of
possibilities stage depicted in Figure 4. This
subprocess' purpose is to develop an overall strategy
that will be reflected in all subsequent planning
39


The Decision Process
r --------------------------- ..............................i
Figure 4 Governing regulations for the
source selection process.
40


documents. It can be considered as an information
decision process with no highly structured procedure,
but, with participants who are selected because of the
subject area information (knowledge) they possess. The
total process consists of an information decision (BSP)
followed by an empirical one (AFR 70-15).
The remainder of the process is controlled by four
major entities: the System Program Office (SPO), which
manages the program from the beginning of acquisition to
system turnover; the Source Selection Authority (SSA),
which possesses the decisioning authority; the Source
Selection Advisory Council (SSAC), which assists the SSA;
and the Source Selection Evaluation Board (SSEB), which
functions to score and rank the bids submitted by the
competing companies.
Once the Business Strategy Panel produces the
Acquisition Plan (AP), the System Program Office (SPO)
develops a document called the Source Selection Plan
(SSP), which is the guiding reference document for the
remainder of the process. One of the important
components of this document is the hierarchical breakdown
of the program into areas, factors, and, depending upon
the complexity of the program, subfactors. Along with
this breakdown are the associated criteria that will be
utilized to evaluate the bids. A set of standards are
41


defined for each criterion from which the evaluation will
be made.
By law the standards must be referred to in the
Request for Proposal (RFP). The reference to the
standards can be obscured and need not be referred to in
the section from which they will be evaluated.
Therefore, bidders must analyze the RFP and synthesize a
response that addresses all of the standards in the
appropriate section to improve their chances of winning.
The Source Selection Advisory Council (SSAC) uses
the Source Selection Plan (SSP), and produces a Source
Selection Plan Review (SSPR). The SSPR is used by the
Source Selection Authority (SSA) for approving the plan.
The Source Selection Evaluation Board evaluates the
bids from the competing companies by measuring them
against the standards. They can issue Clarification
Requests (CR) to the bidders for more information or if
there is something missing they issue a Deficiency Report
(DR), both of which require a response from the bidder.
The SSEB produces it's evaluation report (ER) which
is reviewed for approval by the Source Selection Advisory
Council, which in turn, issues an Analysis Report (AR)
and a recommendation to the Source Selection Authority
(SSA). Then, the Source Selection Authority issues the
Decision Document and the successful bidder is notified.
42


Finally, the process is concluded with a review process
called "Lessons Learned".
Even with this cursory explanation of the process,
it is easy to recognize how some of the architectural
features of Hypertext might be utilized to support the
process. Clearly, collaboration and versioning is
required to emulate the review and approval process.
Once a document is produced it is reviewed and comments
and annotations can be added to explain the reason for
acceptance or disapproval. To coordinate the effort
among the participants some guiding explanation of the
process must be available. In the appendices of the
regulation, there are examples of the types of
documentation that must be produced in this highly
structured procedure.
AFR 70-15 as a Decision Type
The characteristics and requirements portrayed by
this regulation clearly establish it as an empirical
decision. It possesses a highly structured procedure but
initially lacks the information required to make the
decision.
Each step in the process is concerned with the
creation of a document. This means that the substantive
requirement for this process must be concerned with
43


authoring complete documents. The regulation guidelines
require that these documents are consistent from one to
another. Each successor document must conform to the
specifications established by a predecessor document.
For example, the Request for Proposal (RFP) must be
consistent with the Source Selection Plan (SSP). It is
the methodical implementation of this process and
creation of documents which produces the decision. Along
with this ordered creation of documents are specific
guidelines for the form and substance of the documents.
These two characteristics form the procedural requirement
for the process.
The written regulation is an important part of the
process and is used to guide the participants in their
roles and responsibilities. In fact, a considerable
amount of effort is expended by large organizations, such
as the government agencies, to document their processes.
The purpose is to make sure that accepted practices are
followed and time is saved by not designing a new process
each time a decision is required. The description of the
process guides participants who may not be familiar with
its requirements or purpose. In this example (AFR
70-15), participants who are chosen to participate in the
process come with different backgrounds and levels of
experience. Some may be participating for the first
44


time. The written regulation gives them a reference that
can help them understand their function and its
relationship to the whole process.
An implicit requirement for documenting the process
is referred to in the regulation. This requirement is
expressed by the need to conduct a "Lessons Learned"
activity upon concluding the process. There are no
explicit guidelines for preserving the versions of
documents or the elements of collaboration, such as
annotations made to the documents. Instead, it is
assumed that this information will be retained by the
participants. Not having a specific means of capturing
this information can be considered a flaw in the design
of this system. The loss of document versions and
collaborative elements jeopardizes the usefulness of a
"Lessons Learned" activity.
Effectively involving the participants in the
process is a typical challenge to the process managers.
The participants are taken out of their normal
assignments to participate in the process. This can
become an expensive undertaking if they are not used
efficiently. Involvement can become very protracted if
the groups must take time to draw out initial positional
arguments or rehash prior dialogue. In the AFR 70-15
process, much of the activity revolves around authoring
45


particular documents. There is no requirement for
extensive group discussions. Even the scoring and
ranking of bids is performed individually and is compiled
without group discussion. Therefore, this group process
does not require extensive group interaction. In fact,
the process may actually be enhanced by suppressing
interaction. For example, if a meeting is held in which
a high ranking officer expresses her preferences, lower
ranking individuals may be influenced. Interaction must
be accomplished without permitting coercion. Therefore,
the process utilizes multiple roles to prevent bias by a
single entity. There is no chance for an entity to usurp
authority or responsibilities.
The above discussion relates the manual system to
the framework of decision types and the requirements for
all group decision making. A more detailed analysis is
required to create specifications for prototyping the
system.
An Overview of the System's Entities
An analysis was undertaken to establish the
specifications of the system. The analysis shows that
there are two basic types of entities: group entities
such as the SSA, SSAC, etc. and information or document
entities such as the RFP, SSP, etc. Also, there are
46
I


three primary relationships between group entities and
information entities. Group entities either produce,
review/approve, or utilize an information entity. The
three relationships are graphically depicted using
different line style drawn between a group entity and an
information entity. The resulting diagram (referred to
as a PRU diagram) is shown in Figure 5.
The next step in the analysis revealed the required
information associations between information entities.
These associations represent high level links that form
an information network for the process. This network
represents the order in which information must be
produced and the requirement for referencing a document's
predecessor(s) during authoring. These information links
are depicted in Figure 6.
The aim of these first two stages is to relate the
functional relationships of the system to the information
requirements. Each entity relationship that defines a
function (produce, review/approve, utilize) could then be
mapped into the information framework (Figure 7). This
assists the designer in defining linking and screen
layout requirements.
In order to define the details of the links between
the information entities, each entity must be modeled in
detail. There were no documents available to provide a
47


PRODUCE / REVIEW / USE
Figure 5 PRU Diagram
48


Figure 6 Information Framework


Pru Diagram (Entity Relationships)
Figure 7
50


detailed structure of the information but two facts were
ascertained from the regulation regarding the information
organization: (1) the information is predominantly
organized in a hierarchical fashion, such as in a
technical manual and; (2) there is cross referencing
between information entities. An example of the latter
is that each bid must have a section that describes how
each section of the bid corresponds to a section of the
Request for Proposal (RFP).
The last stage of the analysis was to incorporate
additional information required for the decision making
process. This incorporation fulfilled many of the
process requirements including a process description
(regulation), process management (schedule),
collaboration (lessons learned) and role definition
(organization). The implementation of these process
requirements was viewed as a system shell that would link
to the other information sets (Figure 8).
The System Prototype
To demonstrate how Hypertext can support the group
decision making process, a Hypertext-based prototype was
constructed. The first design decision was concerned
with satisfying the substantive requirement for a GDSS.
A designer must decide whether to use a cardfile or
51


Figure B
52


textfile approach. There are two primary types of
information that must be incorporated into the system:
documents and collaborative elements (annotations,
comments, messages, etc.). The cardfile approach is
appropriate for the collaborative elements. Each
collaborative input can be represented by a card (or
record) of a cardfile. However, not all forms of
documents are easily represented by a cardfile. But, in
the AFR 70-15 process, the documents are broken down and
indexed into small sections and subsections that make a
cardfile approach practical. The major concern is
whether a field on a card can be large enough to handle
the largest single indexed section (or subsection). In
this case, the ability to handle 150-200 lines of text
(80 char/line) was considered sufficient.
Another related and important consideration
associated with the information representation approach
(cardfile vs textfile), is the detail required to define
a link. This includes the size of an addressed node and
the size of the feature that will represent a link
(button).
In the cardfile approach, the smallest element that
can be addressed for a link is a single card. Since most
references in the documents of the AFR 70-15 process are
document sections, this level of address definition is
53


sufficient. A link will be made to the card that begins
a section of the document. If it were necessary for the
link to be made to a single phrase or sentence then a
textfile approach would be better suited.
The use of a cardfile approach imposes some
limitations on defining a link (button). Buttons that
represent links are in the same location for all cards
within a cardfile. Therefore, if it is determined that
links should be defined by a single word in a document,
it is unlikely that the document could be contained
within a single cardfile because the random placement of
words in a document would not be consistent with the
uniform location of buttons. This fact presented a
situation for making a compromise in using the written
regulation as part of the system. Examination of the
regulation shows that there are many unique words and
references that could be used as a link to an expanded
explanation. However, it was felt that the document
should be contained within a single cardfile, to avoid
too many files. To provide as much detail as possible
for defining a link, a card was designed that had buttons
defined for each line of text on the card. Therefore,
the smallest feature that represented a link was a single
line of text.
54


To support the procedural element requirement, two
features were considered necessary: representation of the
order relationship of the documents and the layout of the
information format. The former is implemented by adding
a link from one document to its predecessor(s). This
can be seen in looking at the RFP node which contains a
button labeled "Source Selection Plan". A reciprocal
button does not appear on the Source Selection Plan node
because the SSP is produced prior to the RFP and
therefore no link is required.
There is no specific implementation of formats for
each document in the prototype, however, the SSP node
exhibits the hierarchical organization of information
which would exist in most of these documents. A table of
contents that outlines each section and subsection
organizes the information and allows for quick access to
desired information.
Supporting process management requires satisfying
the involvement and documentation requirement.
Involvement means creating a network environment whereby
a participant can participate in the process remotely.
This is not included in the prototype. It would
necessitate implementing a locking scheme to prevent
conflicting modification of the information.
55


Documenting the process is a very important
requirement for a GDSS. Without process documentation,
there is no means to effectively analyze the group
decision making process and learn how it can be improved.
Both the content and the context of the information must
be preserved in order to demonstrate the effectiveness of
the Hypertext paradigm in satisfying the documentation
requirement. All the collaborative elements must be
appropriately associated with the versions of the
documents that they reference. To accomplish this, a
version of a section of a document is created as another
card in the card file. The collaborative elements are
linked to the appropriate card dynamically. This dynamic
linking is accomplished by assigning the address of the
document section (cardfile and card) to the collaborative
element at the time of its creation.
To demonstrate the utility of the Hypertext paradigm
to support the area of the "Group's Role", the prototype
needed to address the objectivity requirement. This
required that the system should support different roles.
Two roles were considered most appropriate for this
system: author and browser. This was considered a
password feature that would permit the participant to
modify the information, if they were considered an
author, or just browse the information. In this way,
56


someone not assigned an author's role for a particular
document would have no direct means of affecting the
contents of a document. Indirectly, they might try to
affect it by using a collaborative element such as a
comment or annotation.
Finally, the requirement of user preferences had to
be addressed. Two alternatives were considered. The
first was to utilize the Hypertext paradigm to call other
software packages that the participant might wish to use.
However, this necessitates prior knowledge of what
packages would be requested. The second alternative was
to create a node that would accept information from an
industry standard. Therefore, participants could use
whatever tool was desired but must output their
information to the standard. This second approach was
used. This is consistent with the concept of having a
highly structured procedure in which the form and format
of the information are predetermined. Also, it relieves
the.system designer from having to create a system with
too many features and complexity.
The following is a brief explanation of how some of
the architectural features of Hypertext were implemented
to effect the system solution.
57


Overview The Main Screen
Figure 9 shows the system's initial screen. It is
an overview of the prototype's information content. The
labelled boxes in the center of the screen represent the
major information entities of the system. The links
among these entities are not depicted to avoid a
cluttered looking screen.
Surrounding these major entities, are the ancillary
information entities that support the process. Here,
links are depicted to represent access to the information
entities. This interface design directly reflects the
utilization of the analysis results.
Users can access the information in two ways. If
they wish to only browse the information they can select
the box representing that information directly. But, if
they will be producing or reviewing the information than
they must first select the "Organization" button. They
must then identify their role, which is determined by
their organizational entity (Source Selection Authority,
System Program Office), and then they are prompted for
password identification. Successful identification will
then allow them to modify the appropriate information.
58


Figure 9 Overview, The Main Screen
[ User selects information
by cursor or mouse ]
59


A Guided Tour AFR 70-15 Document
To support the requirement for a process description
the actual written regulation was used as a guided tour.
In this way, the document is not only a reference but is
also a means to introduce the system to the user. This
is accomplished by creating links from the explanation of
the procedure to the actual information entities that
form the content of the procedure. For example, Figure
10 is the first screen that the user sees after selecting
the document from the main screen. The user may
sequentially view the regulation by selecting the arrows
or jump to a portion of the document by selecting the
line item from the table of contents (Figure 11). Then,
by selecting the major heading of the section of the
document (Figure 12), the user is presented with the
actual information used in the process (Figure 13).
Approval/Review Versioning
To support the review and approval process, a
versioning feature was implemented. A new version can be
created by authors when they are granted their access
privileges from the "Organization" button (see below,
Security). The versions are accessible for browsing by
selecting the arrow buttons located on the information
frame (Figure 13). All lessons learned annotations are
60


DEPARTKENI OF THE AIR FORCE
Headquarters. US Air Force
Washington. t. C. 28330-5040
AF-RECULATION 70-15
and
AFFARS Appendix AA
Contracting and Acquisitions
FORMAL SOURCE SELECTION FOR MAJOR ACQUISITIONS
This regulation sets policy, assigns authority and resposihilities,
prescribes iwplenenting procedures.for.soliciting and evaluating
and
nt and
as veil
offeror's proposals for najor acquisitions, including develo;
production of najor defense systens, subsystens and conponeoi _
as other najor prograns or projects conpetitively procured Ly the
Departnent of the Air Force. Inis regulation inplenents Federal
Acquisition Regulation (FAR) Subpart 15.6, Source Selection for Major
Acquisitions. It is consistent with BOS Directive 4185.62, Selection of
Contractual Sources for HAjor Defense Systens. and current systens
acquisition and progran nanagenent policies. It applies to all Air Fore
personnel invloved in the source selection process.
Chapter 1 General Infemation Paragraph
Applicability and Scope..................................... 1-1
Objectives or the Source Selection Process.................. 1-2
Terns Explained............................................. 1-3
Policies................................................. 1-4
Sources Selection Authpriig................................. 1-5
<=> C=>
j{Table of Contents!
|Continue|
Returns to
first page.
Sequential paging
LEach line item of contents
branches to section.
Figure 10 First page of regulation.
"Guided Tour"
61


I
Paragraph
Organization............................................ 1-6
Responsibilities and Duties............................. 1-7
Conflicts of interest................................... 1-8
Source Selection Schedule............................... 1-9
Solicitation and Contracts fecunents.................... 1-18
Plants and Visits....................................... 1-11
Interface uith Contractors.............................. 1-12
Foreign Hilitarg Sales and Ioteroational Cooperative
Agreenents............................................. OMITTED
Streanlining the Source Selection Procedures.... OMITTED
Deviations to This Regulation............................. OMITTED
Regulators References.............................SEE ATTACHMENT 2
Chapter 2 Pre-Evaluation Activities
Introduction............................................ 2-1
Business Strategy.............................. ..... 2-2
Delegation or Retention of Source Selection Authority... 2-3
Selection of Prospective Sources........................ 2-4
Source Selection Plan (SSP)............................... 2-5
Solicitations..L
Notice of Source.
______ _____^Selection Action....................... 2-7
Basis of Auard. Evaluation Criteria and Central
Considerations......................................... 2-8
Developing Evaliation Standards........................ 2-9
<3 cz>
flaU
e of Coateo
| Continue!
Selecting Source Selection
Plan (SSP).
Figure 11 Guided Tour
62


of the Marketplace nay range fron contacts with knowledgeable federal
and nonfederal experts and results of recent Market tests to More
fomal sources such as sources-sought announcements, presolicitation
notices and similar announcements for planning or inforMation purposes
in the Coiwterce Business Daily (CBD). Consideration of sources includes
screening by the Snail Business Adninistratio (in accordance with FAR
Fart 19) with an opportunity for then to add sources to the list.
c. FAR Suhpart 5.2 requires a synopsis of the acquisition in the
CBD m advance of the issuance of solicitations to permit interested
finis to respond unless specific exceptios apply.
d. FAR Suhpart 5.1 provides guidelines for issuing solicitations
to potential sources and requestors.
2-5. Source Selection Flan (SSP).
a. The SSF is a key dociMKit far initiating and conducting the
source selection! consequently, it should reflect applicable FnD
guidance or direction and contain the elenents described below to
ensure tinely staff review and SSA approval. The SSP is prepared by the
Program Office. A written SS P is required for all source selections
that Meet the criteria of paragraphs 1-la and b regardless of whether
SSA is delegated to a lower level.

|Table of Contents!
|Continue |
_ Selecting header of
section describing the
information, branches
to information set.
(see Figure 13)
Figure 12 Guided Tour
63


Version browsing.
Figure 13 User reaches actual information.
Only browsing possible from
entering without obtaining
authorization.
64


retained with the versions so that no contextual
relationships are lost (see below, Collaboration).
Collaboration Lessons Learned
Perhaps the most compelling reason for automating
the process is the potential to facilitate dialogue and
communication in the cooperative decision process.
Though collaboration takes on several forms, such as
annotations, comments and messages, it was decided that
the forms had similar enough implementation requirements
so that feasibility could be demonstrated in one function
called Lessons Learned.
Learning is considered the final stage of the
decision process and special consideration is made in AFR
70-15 for this purpose. In this system, lesson-learned
information is captured while the process is going on.
The creation of a lesson is accomplished by selecting a
button shown on all the information frames (Figure 13).
The user is presented with a lessons learned annotation
card that they can fill out (Figure 14). It is
automatically linked to the information frame where the
user was originally located. Also, an index number is
assigned that represents the point of origin. This
number is used to facilitate review of the information.
65


Select to view
information enity
Index number
assigned to
information entity
Figure 14 Lesson Learned card
66


The review of lessons may be accomplished by
selecting the Lessons Learned button from the main
screen. In doing so, the user is presented with a screen
similar to the main screen. To review the lessons from a
particular information entity the user first selects the
entity before continuing (Figure 15). Then, only those
lessons from that entity are available for review.
Security Organization
To protect the integrity of the information and
provide some security, the links to information can have
either browsing or authoring privileges. Users with the
appropriate authoring privileges enter the information
sets from the "Organization" button on the main screen.
The user selects the identity of their organizational
unit (Figure 16), and then enters a password (Figure 17).
The user can then select a function to perform and
create a new version if desired. Only in this manner can
information be altered.
Distribution and System Openness Schedule
AFR 70-15 specifically describes the sequence of
events that will occur in the source selection process.
It is presumed that individuals will be responsible for
67


Figure 15
Selecting Information Entity
to review Lessons Learned
68


Participant selects organization
they belong to.
Figure 16
Organization Security
69


This progrA* is designed to facilitate and coordinate the source
selection process as described in flip Force Regulation 76-15. If
EKTER TOUR PASSWORD
thesis
BBS

(CPHTlHUEl
SOURCE SELECTION
AUTHORITY
CSS AD
PRODUCE SSP
PRODUCE RFP
|COWIIHUE|
SYSTEM
PROGRAM
OFFICE
CSPOD
Do you Kant to create a new
version? (T/N)
After selecting organization,
user must be authorized.
User then selects function.
Query for new version.
Figure 17 Security/Authorization
70


tracking and coordinating participation in these events.
It was decided to incorporate a schedule into the system
to address this requirement. Also, it was decided that
this functionality would demonstrate the openness of the
system for satisfying user preferences in a distributed
environment.
This was accomplished by using a commercially
available scheduling software package that permits the
export of information in a Dbase format. The user may
access the schedule information by entering the
regulation document, proceeding to the appendix for
Schedule of Events, and selecting the heading (Figure
18). This feature is implemented by using a routine to
read the Dbase file and transfer the information directly
into the node. Similar functionality can be used to
incorporate information supplied by spreadsheets and
other database systems. Hence, user preferences toward
these tools can be supported.
71


Figure 18 Schedule of Events
72


CHAPTER V
CONCLUSIONS
This research has demonstrated an approach to the
design of a distributed GDSS. This approach is
summarized by the following steps.
(1) The first task for the system designer is to
determine the type of decision the system will be
supporting. Even though both discussion and authoring
are parts of an entire decision process, there can be
more emphasis on one activity than the other. This
points out the importance of having a conceptual model
such as the decision type classification. It relates the
decision problem to the activities necessary to support
them. However, there is no single design that can be
used for every decision problem of a particular type.
Therefore, a tool is required to customize a system
solution for a particular problem. An architectural
design for such a tool was revealed during this research,
which is explained later in this chapter.
(2) The requirements of the decision process should be
examined. These will provide detail to the system's
specifications.
73


- Consideration of the substantive requirements will
establish whether a cardfile or textfile is needed for
the system. An alternative is the development of a
Hypertext system which could employ both types. If so,
it would be possible to incorporate more loosely
structured documents then those in this system without
compromise.
- Consideration of the procedural requirement
identifies the ordered linking of the information that is
produced in the process and the forms and formats of that
information.
- A description incorporated into the system is
required to guide the participants. In this study, the
exact same format of the regulation was used in the
prototype. In other words, the document was input as it
appeared in printed form. Examination of the literature
suggests that it might be better to redesign the document
for better utilization of Hypertext's linking [18] [27].
- Analyzing the documentation requirements helps
identify the types and associations of collaborative
elements. Also, it is necessary to identify the support
features required for viewing, searching and summarizing
this information.
- The involvement requirement establishes the need
for a network. However, a group decision process may
74


still require face-to-face meetings. It must be
determined whether or not the system would be used during
these meetings. If it is to be used by the participants
in a meeting room environment then the literature on
systems that support these activities must be considered.
However, the system proposed in the prototype is mainly
designed as a distributed one.
- The analysis of comprehensiveness identifies
specific types of information to be incorporated into the
system.
- The examination of objectivity identifies the type
of rhetorical model used for representing the discussion
and the structure of the participation. The structure of
the participation establishes what user roles are
required.
- The examination of preferences reveals what tools
the users are currently using. This will establish the
necessity for creating nodes and data import facilities
to handle the integration of these tools with the system.
- The usability of the system is an overall design
issue that must be examined with the development of an
application which will be reviewed for user acceptance.
(3) An analysis should be performed to describe the
manual system that is being automated. By analyzing the
75


relationships between the organization and information
entities and the functional relations, the requirements
for each relationship can be identified. The tools that
were used in this research could be useful for similar
decision problems. The PRU diagram can be used in almost
any empirical decision making problem situation. The
mapping of the functions (relationships) of the PRU
diagram to the information network describes the
information access requirements for any particular
function. Also, the association between additional
information requirements of the process and the
information network can be depicted in the manner of the
overview presentation in the prototype.
(4) The architectural features of Hypertext should be
correlated with the requirements. This step should
detail how each feature can support the overall system
requirements.
(5) Implement.
A GDSS Tool Architecture
The following design features were revealed during
the prototype implementation. These features can be used
76


for a GDSS tool for the decision type considered in this
research.
Overview Creation
A component of the GDSS tool is for developing a
high level model of the process. This model will
represent the basic information content of the system.
Each of the information entities must then be categorized
by type.
Information Layout
Once the information has been properly identified as
to type, the specific layout for each information entity
must be defined. Since the collaborative elements can be
represented in the manner of a cardfile, a form generator
is required to show how this information would be input
and presented. If the information is considered to be a
document then standard guidelines for structuring the
document will facilitate its layout. Separate sections
must be identified for features such as a table of
contents, appendices, etc. Graphic elements could be
supported as a separate file. Viewing a reference to a
figure could be performed using an implicit link by
specifying the figure number.
77


Link Manager
This facility would assist in laying out the buttons
on the information entities. Because access to the
collaborative elements would be desirable from anywhere
in the system, these would become standard selectable
features on all other nodes. For example, a lesson
learned, annotation or comment button would be available
for each document cardfile.
Function Manager
Each function that will be performed in the process
will probably require access to other information
entities for reference. These references establish
additional link requirements. For example, if someone is
responsible for evaluating a bid, they would probably
require at least three entities of information for
referencing: an evaluation form, the description of the
solicitation and the bid(s) itself. Therefore, from the
bid evaluation form, buttons must be available for the
participant to transverse to the solicitation and the
bid(s).
78


Security Manager
To facilitate the design of a group process that has
subgroups, some means of identifying groups, their
membership and their access privileges is necessary.
Additional Research
There are three areas towards which additional
research should be directed. User acceptance of working
in this type of environment must be tested. Even though
a system can be created to accomplish the tasks of the
decision making process, it is not yet known whether it
is socially acceptable. Users may not be willing to
relinquish any perceived benefits of working together in
proximity to become part of a distributed process.
Fortunately, there are many research efforts underway
that are studying the problems of collaborative
authoring. These efforts should add much to this area.
The analysis process must be refined to define the
specific linking requirements for a more complex data
model. For example, in the prototype the RFP node is
linked to the SSP node. However, this is a large scale
link. It essentially links the entire cardfile. What
might be required is a link from a specific card in the
RFP node to an appropriate one in the SSP cardfile. This
requires more examination of the possible document
79


formats in this process and what detailed explicit
linking is required. Also, it is necessary to know
whether the documents and their references are
sufficiently standardized so that all references can be
determined during the initial system design. Thereby,
the participants are only required to fill in the
information and add collaborative elements. If more
flexibility is required for making interdocument
references during the process than a means of dynamic
linking will be required. Finally, and most importantly,
research must continue in the development of the GDSS
tool. Even though the possibility of using an automated
system to support AFR 70-15 has merit, it may be too
risky to implement a total solution without further
understanding of user acceptance. Therefore, this tool
would allow process designers to develop solutions to a
large number of smaller decision making problems. The
experienced gained can be used to refine the requirements
for a GDSS that could support AFR 70-15.
80


BIBLIOGRAPHY
[1] Akscyn, R. M., McCracken, D. L., Yoder, E. A.,
KMS: A Distributed Hypermedia System for Managing
Knowledge in Organizations. Communications of the ACM,
Vol. 31, No. 7, July 1988.
[2] Austin, L. C., Liker, J. K., and McLeod, P. L.,
Determinants and Patterns of Control Over Technology in a
Computerized Meeting Room, ACM CSCW Proceedings, 1990.
[3] Bonczek, R. H., Holsapple C. W., and Whinston A. B.,
Developments in Decision Support Systems, Advances in
Computers, Academic Press, Inc., No. 23, 1984.
[4] Carlson, D. A., Hyperintelligence: The Next
Frontier, CACM March 1990, Volume 33, Number 3.
[5] Carroll, J. M. and Wendy A. Kellogg, Artifact as
Theory-Nexus: Hermeneutics Meets Theory-Based Design. ACM
CHI'89 Proceedings May 1989.
[6] Conklin, J. and Begeman, M. L., gIBIS: A Hypertext
Tool for Exploratory Policy Discussion. ACM Transactions
on Office Information Systems, Vol. 6, No. 4, October
1988.
[7] Delisle, N. M. and Schwartz, M. D., Contexts A
Partitioning Concept for Hypertext, ACM Transactions on
Office Information Systems, Vol. 5, No. 2, April 1987,
Pages 168-186.
[8] Drucker, P. "The Practice of Management", New York:
Harper & Row, 1964.
[9] Engelbart, D. C., Knowledge-Domain Interoperability
and an Open Hyperdocument System, ACM CSCW Proceedings,
1990.
[10] Franklin, C., Hypertex Defined and Applied. Online
May 1989.
[11] Grudin, J., Why CSCW Applications Fail: Problems in
the Design and Evaluation of Organizational Interfaces,
Conference on Computer-Supported Cooperative Work, 1988,
pp. 85-93.
81


[12] Halasz, F. G., Reflections on Notecards: Seven
Issues for the Next Generation of Hypermedia Systems,
Communications of the ACM, Vol. 31, No. 7, July 1988.
[13] Ishii, H., Teamworkstation: Towards a Seamless
Shared Workspace, AC CSCW Proceedings, 1990.
[14] Janis, I. L., "Groupthink: psychological studies of
policy decisions and fiascoes", Boston: Houghton Mifflin,
1983.
[15] Jung, C. G., Psychological Types, London: Rutledge,
1923.
[16] KunzW. and Rittel H., Issues as Elements of
Information Systems. Working Paper No. 131, Institute of
Urban and Regional Development, Univ. of Calif, 1970.
[17] Lee, J. SIBYL: A Tool for Managing Group Decision
Rationale, ACM CSCW Proceedings, 1990.
[18] Martin, J., "HYPERDOCUMENTS & How to Create Them",
Prentice-Hall, 1990.
[19] Mason, R. 0. and Mitroff, I. I., Challenging
Strategic Planning Assumptions: Theory, Cases, and
Techniques. New York: Wiley-Interscience, 1981.
[20] Minch, R. P. and Sanders, G. L., Computerized
Information Systems Supporting Multicriteria Decision
Making. Decision Sciences, 17(1986), 395-413.
[21] Minch, R. P., Application and Research Areas for
Hypertext; in Decision Support Systems. Journal of
Management Information Systems. Winter 1989-90 Vol. 6
No. 3.
[22] Malone, T. W., and Crowston, K., What is
Coordination Theory and How Can It Help Design
Cooperative Work Systems, ACM CSCW Proceedings, 1990.
[23] Minch, R. P., Decision Support Systems Process
Tracing Using Hypermedia, Proceedings of the Twenty-
Fourth Annual Hawaiian International Conference, IEEE
1991, pp. 442-451.
[24] Mintzberg, H., Structure in Fives: Designing
Effective Organizations, Prentice-Hall, 1983.
82


[25] Norman, K. L., Models of the Mind and Machine:
Information Flow and Control Between Humans and
Computers, Advances in Computing, Academic Press, Inc.,
1991.
[26] Neuwirth, C. M., Kaufer, D. S., Chandhok, R.,
Morris, J. H., Issues in the Design of Computer Support
for Co-authoring and Commenting, ACM CSCW Proceedings,
1990.
[27] Nielsen, Jakob, Hypertext & Hypermedia, Academic
Press, Inc. 1990.
[28] Nutt, P. C., Making Tough Decisions, Jossey-Bass
Publishers, 1989.
[29] Shepherd, A., Mayer, N., and Kuchinsky, A., Strudel
- An Extensible Electronic Conversational Toolkit, ACM
CSCW Proceedings, 1990.
[30] Sprague, R. H. and Carlson E. D., Building Effective
Decision Support Systems, Prentice-Hall, 1982.
[31] Stotts, P. D., and Furuta, R.: "Adding browsing
semantics to the hypertext model," Proc. ACM Conf.
Document Processing Systems (Sante Fe, NM, 5-9 December
1988), pp. 43-50.
[32] Toulmin, S. E., The Uses of Argument, Cambridge
University Press, 1958.
[33] Trigg, R. H., Guided Tours and Tabletops: Tools for
Communicating in a Hypertext Environment, ACM Transaction
on Office Information Systems, Vol. 6, No. 4, October
1988, pp. 398-414.
[34] Yakemovic, K. C. B., Conklin, E. J., Report on a
Development Project Use of an Issue-based Information
System, ACM CSCW Proceedings, 1990.
[35] Yourdon, E., Modern Structured Analysis, Prentice
Hall, 1989.
[36] Cerveny, R. P., Garrity, E. J., Sanders, G. L., The
Application of Prototyping to Systems Development: A
Rationale and Model, Journal of Management Information
Systems/FALL 1986, Vol. Ill, No. 2.
83


[37] Galegher, J. and Kraut, R. E., Computer Mediated
Communication for Intellectual Teamwork: A Field
Experiment in Group Writing, ACM CSCW Proceedings, 1990.
[38] Sheperd, A., Mayer N., and Kuchinsky, A., Strudel -
An Extensible Electronic Conversation Toolkit, ACM CSCW
Proceedings, 1990.
[39] Nielsen, J. and Lyngbaek, U., Two Field Studies of
Hypermedia Usability, in Green, C. and McCleese, R.
(eds.) Hypertext: Theory into Practice II, INTELLECT
Press, 1990.
[40] Ellis, C. A., Gibbs, S. J., Rein G. L., Groupware:
Some Issues and Experiences, Communications of the ACM,
January, 1991.
84