The Coast Guard's KSS Project

STEVEN O . KIMBROUGH Department of Decision Sciences/6366University of PennsylvaniaPhiladelphia, Pennsylvania 19104-6366

CLARK W . PRITCHETT united states Coast Guard Research andDevelopment Center

Avery Point, Groton, Connecticut 06340

M I C H A E L P. BIEBER computer science DepartmentBoston CollegeChestnut Hill, Massachusetts 02167-3808

H E M A N T K. BHARGAVA Naval Postgraduate SchoolCode 54BHMonterey, California 93943-5000

Since June 1986, the University of Pennsylvania has been un-der contract with the Coast Guard to provide support for theCoast Guard's KSS (knowledge-based decision support sys-tems) project. A principal output of the KSS project has beenMax, a DSS shell or environment, originally designed to sup-port modeling tasks during decision making for ship acquisi-tion. Max is innovative in a number of ways: (1) it is a docu-ment-oriented DSS, (2) Max documents are generalized hyper-text documents for which the buttons and linkages toassociated information are set up dynamically at run time bythe system, and (3) Max contains a model management system,called TEFA, which can represent and evaluate a broad rangeof models. In addition, TEFA is able to represent a rich body ofinformation about its models and data, and this meta-informa-tion is available through the generalized hypertext facilities ofsystem. Max has been delivered to the Coast Guard and is inuse. Several important Coast Guard and Navy models havebeen implemented in Max at very low cost.

Since June 1986, the University of Groton, Connecticut to provide support for

Pennsylvania has been under contract the Coast Guard's KSS (knowledge-basedwith the Coast Guard's R and D Center at decision support systems) project. ThisCopyright © 1990, The lnsHtute of Management Sciences DECISION ANALYSIS—SYSTEMS0091-2102/90/2006/0005$01.25 GOVERNMENT SERVICES—COAST GUARD

INTERFACES 20: 6 November-December 1990 (pp. 5-16)

KIMBROUGH ET AL.

support has included systems analysis,management science modeling, conceptdevelopment, and software design and im-plementation. Work on the KSS project hasproceeded through the close cooperation ofthe University of Pennsylvania, the R andD Center, and the Coast Guard's Office ofAcquisition in Washington, DC. The Uni-versity of Pennsylvania and the R and DCenter have done the actual work on theproject. The Office of Acquisition, which ischarged with acquiring major systems inthe Coast Guard, has been a willing cus-tomer and provided information and feed-back on various aspects of the project. Aprincipal output of the KSS project hasbeen Max, a DSS shell or environment[Kimbrough 1986], originally designed tosupport modeling tasks during decisionmaking for ship acquisition [Bhargava,Bieber, and Kimbrough 1988; Bhargavaand Kimbrough 1990; Bieber andKimbrough 1990; Kimbrough et al. 1986].

A DSS is an interactive software tool forworking with models and data. A KSS (theCoast Guard's term) is a DSS plus intelli-gence and a richer concept. In developingnew software, our practice has been to be-gin by developing an application theory, orhypothesis, regarding why the software isneeded and what it should be used for.Following this, we develop a concept forwhat the software should be about, how inthe abstract it should work. We then de-sign representation schemes for the sys-tem's objects (the various entities, for ex-ample, models and data, that the systemmust reason about and operate upon), theoperations supported in the system, andthe control mechanisms for the system.Our debt to the Sprague and Carlson

ROMC (representations, operations, mem-ory aids, and control) framework shouldbe clear [Sprague and Carlson 1982]. Toour way of thinking, memory aids, the Mof the Sprague and Carlson ROMC frame-work, are elements of the system conceptwhose specific implementation aspects arecovered under representations, operations,and control.

A KSS is a DSS plusintelligence and a richerconcept.

We subscribe to the argumentation the-ory of DSS, according to which a mainpurpose of a decision support system is tosupport the construction, evaluation, andcomparison of arguments for courses of ac-tion [Kimbrough 1987]. (DSSs are also use-ful for reasons of convenience—a DSS canmake working with data and models mucheasier—and for reasons of insight—a DSScan deliver information that is critical forgaining insight into the decision problemat hand. Reasons of argumentation, how-ever, were a main motivating impetus forour work.) We use the term argument in itslogical sense, to indicate a collection ofstatements, including a conclusion andzero or more premises. Put differently,DSSs are for constructing and examiningreasons for doing things. The CoastGuard's Office of Acquisition is interestedin acquiring ships and aircraft. This costsmoney and must be justified with reasons[Kimbrough 1982]. Their underlying pur-pose for a DSS is to support the develop-ment of the best possible reasons for thebest possible course of action in acquiringships and aircraft.

INTERFACES 20:6

KSS

To date with Max we have aimed at amodest approximation of this goal largelybecause DSSs in general and DSS featuresin particular have traditionally been cate-gorized as either data-oriented or model-oriented [Alter 1977]. This may be correctas a description of actual practice, but webelieve that a third orientation is needed inDSS. Assuming the argumentation theoryfor decision support, our application the-ory (for DSS in the Coast Guard's Office ofAcquisition) has been that the KSS soft-ware should be a tool that is useful in con-structing decision reports, reports that rec-ommend courses of action and documentthe reasons for them. While they incorpo-rate data and the results of model runs,these reports essentially make recommen-dations and provide support or reasons forthem. Our fundamental hypothesis in de-signing Max has been that what is neededis a document-oriented DSS that could alsobe an effective tool for working with mod-els and data. We think that a document-oriented DSS is a reasonable step towardsa more thoroughgoing argumentation DSS.(We credit David Ness with persuadingone of us [Kimbrough] to appreciate theimportance of document handling in DSS.)Major Systems Acquisitions at the CoastGuard

The Coast Guard uses ships (cutters) andaircraft (airplanes, helicopters, and lighter-than-air vehicles) in conducting its mis-sions. Eventually, a particular class of asset(cutter or aircraft) wears out through use orbecomes technologically obsolete and eco-nomically unsupportable or is no longermatched to the missions it is called upon toperform. Some of these problems can bedelayed or overcome by upgrading systems

or overhauling or modernizing, but even-tually an entire class of resources must bereplaced. The Coast Guard, for example, iscurrently examining fleets of high-endur-ance cutters and medium-range helicop-ters.

The federal government has establishedand defined a process that must be fol-lowed in acquiring new systems, includingclasses of cutters and aircraft. The processwas delineated by the Office of Manage-ment and Budget in its now famous A-109circular (1977). The acquisition process formajor systems, such as a fleet of ships, cantake 10 or more years from inception tothe point where a contract is actually let tobuild the first vessel. The responsible officemust establish mission needs and opera-tional requirements for the new system. Allreasonable alternatives must be considered.Each alternative might be played through ascenario or series of models to forecast itsperformance on items of interest, such asmission performance or logistics. Analysesare periodically required for various as-pects of the problem throughout the life ofa major system acquisition project. Forlarge contracts, prototypes may be builtand tested before the final contract is let.Ultimately, a trade-off between cost andperformance must be made and the alter-natives must be ranked. At various stagesin the process, these evaluations and anal-yses must be documented to satisfy the ex-ecutive department that wants the re-sources (in the case of the Coast Guard,the Department of Transportation) and theCongress, which is being asked to appro-priate the money.

During the next 10 years, the US CoastGuard will invest more than a billion dol-

November-December 1990

KIMBROUGH ET AL.

lars in acquiring replacements for its pres-ent, aging fleet. The cost of staffing, oper-ating, and maintaining these assets will beseveral times the acquisition cost. Becauseof the importance and complexity of theproblem of acquiring such major systems,the Coast Guard initiated the KSS project.It was aimed, in part, at systematically de-veloping software to support decisions onacquiring major systems. The goal is toproduce a series of specific KSSs to supportparticular acquisition projects that wouldbe based on generic, reusable software.

During the next 10 years, theUS Coast Guard will investmore than a billion dollars inacquiring replacements for itspresent, aging fleet.

Important elements of the context forthe KSS project follow:

(1) The Coast Guard needs to replace itsaging fleet of ships and aircraft.

(2) Replacement of the Coast Guardfleet will occur in a policy and political en-vironment in which funds are limited.

(3) Vessel acquisitions are complex anddifficult and require years of effort andplanning. \

(4) The complexity and difficulty are in-creased by new technology, changing mis-sion requirements, and the fact that findingthe best possible mix of ships and aircraftbecomes more critical with limited re-sources [Bhargava, Kimbrough, andPritchett 1990].

(5) The Coast Guard must conform tothe A-109 process.

(6) Coast Guard analysis personnel and

decision makers are often not trained inmanagement science and information sys-tems and often serve as acquisition ana-lysts for only one or two years.

(7) Historically, the analysis of alterna-tives has been weak and has relied verylittle on management science techniquesand decision support systems.

(8) Although the existing Coast Guardpersonnel are overextended, they must re-spond to difficult questions from the De-partment of Transportation and the Con-gress quickly and accurately.

(9) The costs of mistakes are high: a lossof credibility with the Department ofTransportation and Congress and a loss ofdollars paid to contractors for Coast Guardmistakes and to attorneys for litigationsupport.Design Goals

The R and D Center (through a groupled by Pritchett) and the project team atthe University of Pennsylvania (Bhargava,Bieber, and Kimbrough) identified the fol-lowing design goals for the KSS softwareearly in the project:

(1) To design and build reusable KSSshells [Kimbrough 1986];

(2) To integrate models and data from avariety of sources;

(3) To produce KSS software that is use-ful and easy for novices to work with;

(4) To employ commercially availablesoftware tools whenever possible;

(5) To use highly modular, flexible, andmaintainable code that can be located on avariety of machines;

(6) To represent large amounts of infor-mation about models and data, and to pro-vide easy access to this meta-information[Bhargava and Kimbrough 1990]; and

INTERFACES 20:6 8

KSS

(7) To identify the main classes of usersand design the system for their needs.

Why have these high-level design goals?The answer is pretty much self-evident,but we paid special attention to severalpoints (5, 6, and 7). The key idea behindhow we built intelligence into the KSS,that is, into Max was to declare informa-tion about models, data, and other systementities (6) as well as to represent these en-tities directly. Also we identified three ma-jor classes of users (7): analysts, browsers,and builders. Analysts are in the businessof developing (major systems acquisition)options and comparing them. Analystsmake recommendations to decision mak-ers, and in doing so they create reports af-ter exercising models and examining data.Browsers are more casual users of the KSS.They need an easy way to explore docu-ments and information, including data andmodels. Builders need to put together spe-cific models, data, and other informationdirectly and rapidly. The builders (whomwe envisioned to be R and D center man-agement scientists) configure the KSS shellenvironment to create specific DSSs for useby analysts and browsers.

We will discuss building highly modular,flexible code (5) later. We assumed a build-and-revise (iterative) strategy—rather thana specify-and-implement strategy—for theproject. (The present version of Max is amuch-revised version of the second re-write.) This universally recognized strategyproduces workable, usable early releases offhe software, which can then be modifiedin response to informed customers' direc-tions. Happily, we are in fhat position. Wedelivered an early, workable version of thesystem which is in use and is undergoing

frequent revisions.To justify the need for a DSS to Coast

Guard management, and specifically forthe DSSs to be produced under the KSSproject, we made the following points:

(1) A DSS delivers detailed informationto decision makers effectively.

(2) A DSS produces reliable answers toqueries quickly. (This is particularly impor-tant for maintaining credibility with execu-tive agencies and with Congress.)

(3) A DSS can reduce the costs of pro-ducing information, analyses, and reportsfor decision makers.

(4) A DSS facilitates more effective useof existing models and data. (This was aparticularly telling point with the CoastGuard managers, because they had in-vested heavily in modeling.)

(5) A DSS can lead to better decisionsand recommendations (valuable for theirown sake and for maintaining credibilitywith executive agencies and Congress).

(6) A DSS can facilitate more effectivepresentation and justification of decisionsand recommendations.

(7) A DSS can, by collecting models anddata in a single system, help with the insti-tutional memory problem.Results

We developed two KSS concepts: level 1and level 2. Level 2 builds upon level 1.We developed both concepts in response toa Coast Guard captain's request for a sys-tem that could "tell me where the numberscome from" (B. C. Miller, then of the Of-fice of Acquisition). The captain under-stood that acquisition recommendationsare based on assumptions, some of whichare solid, some of which are not. He wasasking for a system that could tell him eas-

November-December 1990

KIMBROUGH ET AL.

ily and quickly the source and quality of agiven assumption, as well as the assump-tions underlying a given figure. His requestis certainly consistent with the argumenta-tion theory of DSS: he wanted DSS sup-port to help him examine the premises ofarguments or the assumptions behind thereasons and reasoning presented in DSSreports.

We set out to provide such a system andto have the KSS shell software—ratherthan the system builder—determine andmanage the links between the numbersand the information about them. More-over, we sought to do so in a very general-ized fashion, applicable very broadly.Level 1 KSS Concept: Document-Oriented DSS

The delivered and working version ofMax (which is still undergoing modifica-tions) is an instance of the level 1 KSS con-cept; it is a document-oriented DSS. TheKSS shell software provides two mainclasses of features: interactive (hypertext-style) documents and model management.(Its data management capabilities are cur-rently quite basic, but we are enhancingthem.) Our DSS argumentation theory, asapplied to Max, has it that a DSS shouldsupport an analyst in developing a reportrecommending a course of action and giv-ing the reasons for it. The KSS shell is ori-ented towards constructing such reports.This is reflected in the high-level design ofthe shell, which contains two main mod-ules, Maxi and TEFA.

The TEFA module manages a broadclass of mathematical models. (In the de-livered version of Max, TEFA handles hier-archical, conditional equational models. Itsupports models that consist of many

equations, but not systems of simultaneousequations. Basically, TEFA's present modelrepresentation and execution capabilitiessubstantially exceed those of spreadsheetprograms. We have developed a successfulprototype for representing mathematicalprogramming models, TEFA can translatesuch models from its internal format tothat required by a commercial solver.) Fur-ther, TEFA can express essentially any in-formation about a model or a variable for amodel—for example, its source, its reliabil-ity, and its dimensional characteristics.Moreover, TEFA can automatically usesuch information to provide such featuresfor the KSS as validity checking and re-porting on models. The documentation formodels in TEFA can be made remarkablyclear, as is the actual declaration of themodels in the system. Model documenta-tion includes a typeset mathematical for-mulation of the model as well as the actualdeclarations for the model in Max,

We designed TEFA with the entire mod-eling life cycle in mind and continue to im-prove it. The modeling life-cycle frame-work that we worked with includes thefollowing elements:

(1) Identification of the sort of modellikely to suit the problem at hand,

(2) Formulation and specification of aparticular model,

(3) Implementation and validation ofthe model from step 2,

(4) Determination of parameter values(this typically requires data collection andanalysis, and can benefit from data man-agement tools),

(5) Solution of the model,(6) Fielding and use of the model, and(7) Modification of the model in re-

INTERFACES 20:6 10

KSS

sponse to field-based experience.The Maxi (Max interface) module pro-

vides the interactive documents, or hyper-text features. (See Bhargava, Bieber, andKimbrough [1988]; Conklin [1987]; Halasz[1988]; Marchionini and Shneiderman[1988]; and Minch [1990] for discussion ofhypertext and hypermedia.) The idea is tobuild reports in which items—includingnumbers—are linked automatically to per-tinent information about them. What wehave is a broader, deeper, more generalform of hypertext, which we call general-ized hypertext [Bieber and Kimbrough1989; 1990]. Standard hypertext systemsprovide system-level support for the userto navigate among the nodes in a hyper-document, using links that have been setup by a builder using the editing facilitiesof the system. In generalized hypertext, asimplemented in Max, the system can createlinks and nodes (reports) dynamically atrun time, thereby eliminating a great dealof work by the document builder. (SeeBieber and Kimbrough [1989, 1990] for adetailed discussion of these points.)

The architecture for the level 1 imple-mentation is highly modular and robust.There is an internal communications pathbetween the Maxi and TEFA modules,which communicate by sending messagesin a recursively defined formal language.This structure allowed Maxi and TEFA tobe developed quite independently. Also,the architecture for TEFA is itself highlymodular and robust, and has proven suc-cessful for iterative development. Themodule consists of a number of knowledgebases, inference engines, and utility pro-cesses, all potentially in a many-to-manyrelationship, with everything ultimately

controlled by a meta-level inference enginethat tasks out work to the appropriate in-ference engines and utility processes. Us-ing this architecture (TEFA has more thana score of inference engines), we havebeen able to add features to the systemmainly by adding new inference enginesand (occasionally) new knowledge basesand utilities, and by making very minorchanges to the meta-level controlling infer-ence engine. We call this architecturaltechnique generalized meta-level inference.

In sum, the level 1 concept may be sum-marized as consisting of the followingideas:

(1) Model management (which includesdeclarative representation of models, dec-laration and utilization of informationabout models and data, model evaluation,and features to support activities through-out the modeling life cycle);

(2) Interactive documents (which in-clude generalized hypertext, an interface tothe model management system, and auto-mated linking of information items withone another);

(3) Generalized meta-level infer-ence; and

(4) Internal communication via a formallanguage.

Max, level 1, has been delivered and isbeing used. Improvements in Max are con-tinuing to be made. A number of CoastGuard and Navy models have been incor-porated into the system (including ASSET,CAPS, Maintenance, and PATROL) andothers are being developed for implemen-tation in Max. With the KSS software, wewere able to re-implement ASSET and PA-TROL, two large models, in less than fourperson-weeks. ASSET was originally de-

November-December 1990 11

KIMBROUGH ET AL.

veloped by the Navy, and PATROL wasdeveloped by Pdtchett [1986] of the CoastGuard's R and D Center. Both of the origi-nal implementations cost more than$100,000, The Max KSS greatly reducesthe costs of implementing and maintainingmodels. Further, these models are muchmore valuable in the KSS on a desk-topMacintosh, than they were implemented inFORTRAN on a distant minicomputer, us-ing different user interface conventions.The models are more accessible in the KSS,and the user has much more informationabout them and can create reports directlyfrom the outputs of the model runs.Level 2 KSS Concept: DSS Executive

Our level 2 concept for the KSS origi-nated with a simple thought: it is illumi-nating to distinguish between the subjectmatter of a decision problem and the pro-cess or procedure undertaken to make thedecision. For example, the OfBce of Acqui-sition may be deciding what to do aboutreplacing an aging fleet of buoy tenders.So, the subject of the decision is replace-ment of buoy tenders. In making the deci-sion, however, the Office of Acquisitionmust perform certain tasks: it must assessmission needs, consider alternative meansof keeping buoys in working condition, ap-prove interim recommendations, and soon. These tasks make up the process ofcoming to the decision.

The level 2 KSS concept started with theidea that it would be possible to distin-guish in the KSS software between pro-cess-level features and subject-level fea-tures. At the subject level, we would havea set of features very much like that of thelevel 1 KSS concept. Models could be run,data examined, reports issued, and docu-

ments produced. At the process level, wewould have a model of the procedure bywhich the decision is to be made. Thismodel, and information declared about it,would be used to provide process-levelfeatures.

Specifically, we proposed to model a de-cision process by representing it in an ex-tended work breakdown structure. This isin accord with the Office of Acquisition'smanagement of acquisition projects andship building [Levine 1986; Meredith andMantel 1985; Morris and Hough 1987].The basic KSS level 2 concept is this. Auser of the system could "go" to a particu-lar project represented in the KSS and findcertain data, documents, and reports aboutthe project and its status. Further, the usercould go to a particular node in the proj-ect's work breakdown structure. Thatwould put the user in a local environment,in which he or she could work on the proj-ect by collecting information, creafing ormodifying documents, or by causing infor-mation to be added to that node of theproject. At each node, certain data, docu-ments, reports, and models are available.Since each node constitutes a local envi-ronment, what is available varies fromnode to node.

Information at a node may be keyed inby the user or may come—as MIS reportsor as data—from another computer. In ei-ther case, the KSS may have informationabout the added information. For example,the KSS may have knowledge about themeaning of the row and column headingsin an MIS report from an external system.Similarly, the KSS may record and use in-formation about the entries in an externalreport and may automatically incorporate

INTERFACES 20:6 12

KSS

data from the exterrial report into other re-ports internal to the KSS. Operationally,the user can call up an MIS report (asso-ciated with a particular node) in which ev-ery item in the report is also a generalizedhypertext button (or link icon). Using amouse, the user can direct the KSS to pro-duce a report about any item. For example,a report might supply the source, date, andoriginal location of the data item. Thus, insome sense the KSS may know more abouta report imported from an external systemthan the system that originally produced it,since the new report is linked to informa-tion in the KSS.

In sum, the level 2 concept (DSS execu-tive) may be described as the level 1 con-cept (document-oriented DSS) plus

(1) Intelligence-based integration of dis-tributed MISs,

(2) Interactive MIS reports, and(3) Knowledge-based project manage-

ment, organized around a work break-down structure.

Our concept of project management isvery different from that of existing com-mercial project management systems,which deal only with certain informa-tion—primarily timing information—per-taining to the lowest level nodes in thework structure, which are called workpackets. Given this data, existing systemsare designed to compute schedule-relatedinformation and to help the project man-ager to manage the schedule. We wantedto make the system the central repositoryfor all information relevant to managementof the project. Specifically, for the Office ofAcquisition we want the KSS to become acomputerized and interactive implementa-tion of the Office's Project Manager's Hand-

book, the policy statement by which acqui-sition projects are managed.

Currently, we have developed the level2 KSS to the point where it demonstratesour concept. All the essential elements andfeatures we have described have beendemonstrated with an implementation. Weare developing the needed infrastructure inthe KSS software, refining concepts, andinitiating a complete redesign. In addition,we have working prototypes in HyperCardand in HyperLisp (HyperCard front-endinga Lisp machine), which we are using todisplay concepts to users and to elicitfeedback from them.Working with Max

To give a sense of how Max works, weshall discuss some of the features a userwould employ in a Max application—called Max Financial—to work withASSET, a model used by the Navy and theCoast Guard to estimate ship acquisitionand life-cycle costs. Originally imple-mented in FORTRAN, we reimplementedit in the model representation language ofTEFA by making a series of declarations.The various reports and features we willdescribe are produced inferentially at runtime by Max, that is, by our generalizedhypertext system. They are automaticallyavailable for any model declared in TEFA.This strategy significantly hastens thebuilding of particular DSSs.

We designed Max to support both ana-lysts and executive browsers. Analysts exe-cute models under various data scenarios.Information is returned in standard TEFAreports. The analysts can then "copy andpaste" from these standard reports to cre-ate their own ad hoc final reports. Thestandard reports are themselves interactive

November-December 1990 13

KIMBROUGH ET AL.

documents, dynamically generated withbuttons (naming generalized hypertextlinks) automatically embedded in them.Copying and pasting preserves these linksin both the original and duplicate copies.(The computational cost of this is not ex-cessive, since buttons refer to links, andthe buttons are copied, not the links.) Theexecutive browsers have access to these fi-nal reports, as well as automatic access tothe standard reports via generalized hyper-text linking.

We want the KSS to become acomputerized and interactiveimplementation of the ProjectManager's Handbook.

Imagine that an analyst wants to create areport comparing the total life-cycle costsfor two different ships, a hydrofoil and aSWATH (a small waterplane area twin-hull) vessel. After starting the Max session,the analyst asks for a description of theASSET model. To do this the analyst se-lects the describe command from a menuin Max's menu bar and then chooses theASSET model as the subject of the com-mand. The system produces a report thatdescribes the ASSET model. The report re-sembles a word processing document. Itcontains text and mathematical formulae.Buttons, however, are highlighted in bold-face, indicating that further information isavailable about the objects they represent.

During Max's initialization, the Max ap-plication (under TEFA) passes a list ofcommand options in the communicationsprotocol language to Maxi, the user inter-face subsystem, which then makes themavailable from the menu bar, under Max

Financial. When the analyst chooses one ofMax's menu items, this initiates a dialogwith the Max Financial application. TEFA,the model management subsystem, deter-mines (infers) that the text string "ASSET"is the name of a model node and executesthe describe query as a Max command togenerate (an instance of) a generic reportmodel containing a description, an equa-tional listing, and related top-level models.

The knowledge base is searched forthese components, many of which them-selves are nodes containing subcompo-nents. The text string "ASSET" is treatedas referring to a bundle of virtual (deter-mined inferentially, at run time) links,namely the run, describe, and suggest-scenario links. When the user chooses de-scribe, a virtual report node is generatedafter traversal of a link of type describe,producing the report. Traversing the de-scribe link does not cause an automaticdisplay of canned information. Instead, itcauses a Max procedure (in TEFA) to exe-cute and process data in the knowledgebase to create a composite report nodewhich, as it turns out, is to be displayed.The model management subsystem for-mats this report in the communicationsprotocol language and passes it to the in-terface, which in turn processes it andpasses it on to the screen managementsubsystem. Here it is mapped to the com-puter screen, and its buttons—which havebeen marked by the model managementsubsystem—are highlighted. Buttons aretagged with an internal ID and display in-formation (for example, their basic displaytext and whether it is textual, numeric,monetary, and so forth). The interface usesthis information to determine the actual

INTERFACES 20:6 14

KSS

text representation of the button on thescreen. Buttons denote links, actual or vir-tual. Although they indicate a relation toinformation in the knowledge base, theyare usually not explicitly linked to any-thing. Only when they are queried directlywill a link be determined and traversed.When the user clicks on an "ASSET" but-ton, Maxi sends a message to TEFA, whichthen determines the three things (run, de-scribe, suggest a scenario) it can do withthe ASSET model. Nearly every elementpresented to the user is created dynami-cally at run time by the KSS.

Next, suppose the analyst wants to exe-cute the ASSET model. In order to executethe ASSET model for the user, the systemtraverses a virtual "execution" link (as op-posed to traversing a "describe" link, a"suggest scenario" link, and so forth). As aresult, the system executes the model andgenerates a standard report node compris-ing the major resulting values. Each ofthese values is represented by a hypertextbutton and each button is generated andmaintained by the KSS software.

The final report constructed for the exec-utive browser is typically short. The ana-lyst need do no explicit linking but maycopy portions of system-produced reportsinto the final report, which the analystmay also edit. The KSS software automati-cally preserves the buttons and linked in-formation for text copied from one docu-ment to another. Max Financial supportsmany other features and contains severalsubstantial mathematical models.Conclusion

While we have accomplished a greatdeal, much remains to be done on the KSSproject. We continually identify level 1

features that appear useful. In fact, theworld of generalized hypertext and modelmanagement in DSS has only begun to beexplored. In addition, nearly all of the level2 world remains to be explored and inves-tigated, as well as levels not yet envi-sioned. In addition, we must determinehow best to use and deliver these technol-ogies.

Far from being daunted by these pros-pects, we are excited and deeply engaged.We hope others will work on similar prob-lems and ideas and that technical dialog inthe DSS community will expand andbecome yet more lively.Acknowledgments

This work was funded in part by the USCoast Guard under contract DTCG39-86-C-80348 with the University of Pennsylva-nia, Steven O. Kimbrough principal inves-tigator. Special thanks to Rosie Milan forpatience in implementing required editorialchanges.ReferencesAlter, S. 1977, "A taxonomy of decision support

systems," Sloan Management Review, Vol. 19,No. 1 (Fall), pp. 39-56.

Bhargava, Hemant; Bieber, Michael; and Kim-brougb, Steven O. 1988, "Oona, Max, andtbe WYWWYWI principle: Generalized hy-pertext and model management in a symbolicprogramming environment," Proceedings ofthe Ninth International Conference on Informa-tion Systems, eds., Janice I. DeGross andMargrethe H. Olson (November 30-December3), pp. 179-191.

Bhargava, Hemant, K. and Kimbrough, StevenO. 1990, "On embedded languages for modelmanagement," Proceedings of the Twenty-Third Annual Hawaii International Conference •on System Sciences, ed. Jay F. Nunamaker,IEEE Computer Society Press, Los Alamitos,California, pp. 443-452.

Bhargava, Hemant, K.; Kimbrough, Steven O.;and Pritchett, Clark W. 1990, "A balance

November-December 1990 15

KIMBROUGH ET AL.

sheet approach to fleet mix planning," work-ing paper. University of Pennsylvania, De-partment of Decision Sciences,

Bieber, Michael P, and Kimbrough, Steven O,1989, "On generalizing the concept of hyper-text," working paper. University of Pennsyl-vania, Department of Decision Sciences,

Bieber, Michael P, and Kimbrough, Steven O,1990, "Towards a logic model for generalizedhypertext," Proceedings of the Twenty-ThirdAnnual Hawaii International Conference on Sys-tem Sciences, ed. Jay F, Nunamaker, IEEEComputer Society Press, Los Alamitos, Cali-fornia, pp, 506-515,

Conklin, J, 1987, "Hypertext: An introductionand survey," /£££ Computer, Vol, 20, No, 9(September), pp, 17-41,

Halasz, F, 1988, "Reflections on NoteCards:Seven issues for the next generation of hy-permedia systems," Communications of theACM, Vol, 31, No, 7 (July), pp, 836-852,

Kimbrough, Steven O, 1982, "Pragmatic aspectsof justifying decision support systems,"Transactions of DSS-82, Second InternationalConference in Decision Support Systems, ed,Gary W, Dickson, San Francisco, California(June 14-16), pp, 138-145,

Kimbrough, Steven O, 1986, "On shells fordecision support systems," working paper.University of Pennsylvania, Department ofDecision Sciences,

Kimbrough, Steven O,, Coe, Thomas; Pritchett,Clark; Roehrig, Stephen; Smith, Joseph A;and Sprague, Michael 1986, "A decision sup-port system for evaluation of advanced ma-rine vehicles," Transactions of DSS-86, SixthInternational Conference on Decision SupportSystems, ed, Jane Fedorowicz, Washington,DC (April 21-24), pp, 218-227,

Kimbrough, Steven O, 1987, "The argumenta-tion theory for decision support systems,"working paper. University of Pennsylvania,Department of Decision Sciences,

Levine, Harvey A, 1986, Project ManagementUsing Microcomputers, Osborne McGraw-Hill,Berkeley, California,

Marchionini, G, and Schneiderman, B, 1988,"Finding facts vs, browsing knowledge in hy-pertext systems," /EE£ Computer (January),pp, 70-80,

Meredith, Jack R, and Mantel, Samuel J,, Jr,1985, Project Management: A Managerial Ap-

proach, John Wiley and Sons, New York,Minch, Robert P. 1989/90, "Hypertext in DSS,"

Journal of Management Information Systems,Vol, 6, No, 3 (Winter), pp, 119-138,

Morris, Peter W, G, and Hough, George H,1987, The Anatomy of Major Projects: A Studyof the Reality of Project Management, JohnWiley and Sons, New York,

Pritchett, Clark W, 1986, "PATROL: Volume LModel description and analyst's guide,"USCG Report Number CG-D-05-87, Govern-ment Accession Number ADA-178 168,

Sprague, Ralph H,, Jr, and Carlson, Eric D,1982, Building Effective Decision Support Sys-tems, Prentice-Hall, Inc, Englewood Cliffs,New Jersey,

W. R. Johanek, Captain, US CoastGuard, Chief, Project Support Division bydirection of the commandant, Washington,DC 20593-0001 writes "Although the finalversion of the knowledge-based decisionsupport system (KSS) has not been com-pleted, the prototype shows potential forthe Coast Guard. Plans are underway toexpand this effort to support large seg-ments of information systems and officemanagement. The advanced features suchas automatic linking of data offer great po-tential for improving management effec-tiveness and efficiency. The model buildingcapability of the KSS has already proveduseful. In one working day, a proficientuser of KSS took six pages of equationsand turned them into a working model.The benefits to the Coast Guard of thissoftware lie in its ability to help us do ourjob better. As we continue to use it and ex-ploit its capabilities, we anticipate signifi-cant improvements in the areas of analysis,information systems, and projectmanagement,"

INTERFACES 20:6 16