Using PSL/PSA to
Model Information System Planning for
The United States
Department of the Army Headqarters
Paul D. McDaniel
10180 Bessmer Lane, Fail-fax, Vil-ginia, 22032, USA
( Phone: (103) 918-2488
Headquarters, united states Army
Deputy Chief of Staff for Personnel
ABSTRACT: The US Army first adopted information s¥stem planning
techniques in the early 1980s. What has evolved ~s a complex
automated model of the functions, classes of information,
systems, data flow, organizational responsibility, and their
interrelationships. The intent of this paper is not to explain
the methodology used in this model but to demonstrate the use of
a modern, second generation CASE tool (PSLjPSA) in its
implementation.
This is an information model of a portion of a large military
organization. However, these tools and methods should aid any
large or~anization to better understand and control its
informat~on requirements. The problems encountered, lessons
learned, and recommendations corning from this experience will
also be of value to systems planners and integrators.
\ This paper briefly discusses PSLjPSA, and the background" of
information system planning by the Army. The ~roblems in
attempting to perform information s¥stem plann~ng by manual means
are addressed, as well as the benef~ts of an automated model.
What are the data requirements for an information model? What
analysis must be performed? What naming conventions should be
used and why? What objects are needed? What relationships? How
do they interact? How do these objects and relationships ma~
into PSLjPSA? Answers to these and other questions are prov~ded,
as well as detailed syntax for the PSLjPSA implementation of the
information model. The output requirements for information
system planning are also discussed, and some sam~le reports are
provided. Finally, lessons learned by the exper~ence are shared,
along with recommendations and the current status of the
information modeling efforts.
KEYWORDS: Information Modeling, Information System Planning,
Enterprise Modeling, System Interfacing
DISCLAIMER: Please note that the opinions expressed in this paper
are those of the author and do not represent a position taken by
the united States Army or any agency of the united states
Government. This paper has been cleared for open publication by
the united states Department of Defense on 11 Jan 1989. (885758)
EXPlANATION OF TERMS
The term Business Systems Planning (BSP) refers to an enterprise
modeling methodology developed by IBM, starting in the mid 1960s.
This methodology defines the major functions, processes, classes of
information, and data entities which are used to define a business's
information systems processing. When BSP was adopted by the US Army
in the early 1980s,-the Army decided that Information Systems
Planni.ng (ISP) was a more appropriate term. The main output I?roduct
from such a study is a Business System Plan (BSP) or Informat10n
System Plan (ISP). To avoid further confusing the reader this paper
uses "BSP/ISP" to refer to the methodology and "ISP" only to refer to
the plan.
APPUCABIUTI
This paper directl¥ pertains to a portion of a large military
organization with funct10ns such as direction, control, management,
structure, acquisition, trainin9' distribution, deployment,
sustainment, development, and d1sposition. The concepts and
techniques described are equally applicable to a business which might
add or sUbstitute such functions as production, marketing, order (
processing, etc. In fact, any large organization could use these
tools and methods to gain a better understandin9 and control of its
information requirements. ..Functions and obj ect1ves vary from one
organization to another. This does not alter their need nor their
ability to model the interrelationships of their functional and
informational requirements.
INTENT
The intent of this paper is not to explain the methodology but
to demonstrate the application of it, with adaptations, in an
on-going project using an automated tool, PSL/PSA, and the mapping of
the BSP/ISP methodology into PSL/PSA. The reader will hopefully
obtain some insight into some of the problems encountered, lessons
learned, and benefits to be gained by such an effort.
(
PSL/PSA
Problem Statement Language/Problem Statement Analyzer (PSL/PSA)*
was ori9inally developed in 1968 by the ISDOS research project at the
Univers1ty of Michigan. PSL/PSA was designed as an automated
"entity-relationship-attribute" (ERA) model, and for several years
was used primarily by students, who developed enhancements for it
while doing work toward advanced degrees in systems engineering.
While PSL/PSA was recognized for its power and versatility, it was
condemned for years because of unfriendly, complex and inconsistent
command syntax and a generally accepted reputation for substantial
computer resource consumption.
Largely as a result of these factors, PSL/PSA remained for years
an academic curiosity, with interest outside the university community
mainly by organizations sponsoring the research.
* PSL/PSA is a registered trademark of the Regents of the
University of Michigan.
1
PSL/PSA began to come of age in the late 1970s and early
1980s, as computers became more ~owerful and less expensive. It
became a commercial enterprise w1th the formation of ISDOS, Inc.
in 1983, when many of the research sponsors became customers.
ISDOS later changed its name to META systems and now licenses
PSL/PSA worldwide. A partial rewrite of the PSL/PSA code (from
FORTRAN to "C"), along with the development of several new
companion products by META Systems, has largely rectified the
previous problems of user "unfriendliness", sluggish performance,
and large resource consumption. Carma McClure, an internationally
reco9nized authority on CASE, considers PSL/PSA to be on the
lead1ng edge of second generation CASE tools (defined as having a
complete repository).
PSL/PSA is an exceptionally versatile relationship modeling
tool. The language supports the use of numerous object types,
relationships, commands, modifiers, and reports. It can be used
to model different applications with different methodologies
( throughout all phases of the s¥stem life-cycle. It has been used
for defining system specificat10ns, structured analysis,
structured design, project management, ship maintenance, data
element dictionaries, systems interface modeling, information
architecture modeling, and others - including enterprise modeling
( or information modeling, which is the subject of this paper.
.BACKGROUl\'D
In 1981 the Inspector General of the united States Army
determined that, in order to better evaluate the functioning and
performance of the Army, it was necessary to better define the
functions the Army actually performs. Based on his direction, the
Trefre¥ study (named for the Inspector General), completed in
1982, 1dentified the eight major functions regularly done by the
Department of the Army.
Further studies were conducted and, by applying the BSP/ISP
methodology, the original eight functions evolved into ten
functional areas which became the basis for the Headquarters
Department of the Army (HQDA) Information Systems Plan (ISP)
published in 1983. The HQDA ISP defines the functional processes,
information classes, and entities which make up the HQDA
Information Model. It directs that all staff elements and Army
agencies, major commands and installations conduct similar studies
and produce similar ISPs and information models. It also calls
for the definition of a Data Architecture~ Applications
Architecture, and Geographical/ Technical Architecture, based on
these information models.
In 1983 the US Army Deputy Chief'of Staff for Personnel
(DCSPER) hired a contractor to perform such a study and produce an
Automation Architecture Master Plan for the DCSPER. The
contractor conducted interviews with all top level personnel in
the agency, held numerous conferences with DCSPER staff personnel
with expertise in each of the functional areas, and used the
BSP/ISP methodology to produce the Department of the Army DCSPER
Information System Plan. The DCSPER ISP defined the functional
processes, information classes, entities, and critical success
factors for the DCSPER. The study also identified organizational
proponency (advocacy) and involvement levels for functional
processes, and proponency for information classes, and developed a
list of automated personnel systems which support the processes
pertinent to the DCSPER and developed descriptions for each. The
results of the study were presented in several·formats. Some
2
automated tools were used to produce output products. There was,
however, no linkage between the tools used. As might be expected,
the end products were inconsistent.
In October 1984 the DCSPER Manning The Force Automation
Architecture (MTFAA) Office designed a PSL/PSA database, loaded the
bulk of the data from the DCSPER ISP into it and, by using PSL/PSA,
generated the equivalent of each of the ISP output products the
contractor had produced. These products were consistent with each
other and were produced in far less time.
In late 1984 a second contractor was hired in order to validate
the findings of the first study and begin the definition of a Total
Army Personnel Data Base. The PSL/PSA database was turned over to
the second contractor (who had some in-house expertise with PSL/PSA).
The contractor was shown the PSA output products and told how each
was produced. The contractor argued against using PSL/PSA and stated
that better looking products could be made by other means. The Army
(MTFAA) insisted on the use of PSA outputs for the sake of (
consistency.
The contractor produced a first draft Information Systems Master
Plan, consisting mostly of a collection of PSA outputs. These
outputs included formatted summaries, descriptions, matrices, and
lists. . (
The draft was reviewed by the conference participants who
recommended and submitted changes. The contractor applied the
updates and produced a second draft which was then sent out for
review.
since there were only a few changes received on the second draft
the Army decided to apply the updates in-house. When Army personnel
started to u~date the database they discovered that the contractor
had not appl~ed the earlier updates to the PSL/PSA database but had
instead updated the PSA outputs. The Army took over control of the
database at this time. In January 1986 the MTFAA Office produced the
final DCSPER Automation Architecture Master Plan, using DocGen (the
PSA documentation generation package). The complete package of 500
pages was generated by one command. All output products were
consistent, thus demonstrating some advantages of using an automated
tool to support an ISP.
(
Having consistent output products is obviously essential for
successful information modeling. What comes out is, however, only as
900d as what goes in. The fact that reports are consistent in no way
~nfers that the information is accurate, but it does help to verify
the input. (
INFORMATION MODELING WITH THE BSPIISP METHODOLOGY
Information modeling helps to identify an organization's
functional and informational requirements. These techniques provide
a vehicle for defining the interrelationships between the component
parts of the organization, their functional responsibilities, the
information that they derive and utilize, and how they process that
information. Rather than discuss the specific functional and
informational requirements, this paper shows how this
"meta-information" can be captured, maintained, and recycled back to
the supplier of the raw data by the use of modern CASE technology.
3
What is needed to constl'uct a meaningful and useful information model?
Data - 9Uite a lot of data, simplistic in nature, but
carefully rev~ewed and cleaned up and meticulousl¥ maintained.
There are continual changes in functional respons~bility,
organizational structure, and system environment. As a result,
the information model must be updated regularly in order to keep
it current.
If the ISP is in a manual form it cannot be updated and
rapidly becomes obsolete. Any chan~es would require that the
study which produced the ISP be per~odically redone. This costs a
~reat deal of time, money, and human resources and is totally
~mpractical. It is essential that the information is maintained
in a fUlly automated form so that it can be easily updated as
required, and consistent output products can be produced.
with the use of PSL/PSA, changes are easily entered and
( automatically carried throughout the model. By entering a change
to a given aspect or relationship in one view of the model, the
change will show up in any other view in which the aspect or
relationship is represented. Because of this, changes can be
applied as they occur or become apparent, the model can be kept
( current, and information extracted is always up-to-date.
Analysis - the analysis required is rather basic. It
consists mainly of:
(a) reviewing and cleaning up the input which has
been received,
(b) identifying inconsistencies, and
(c) correcting them.
This is not to say, however, that the review and clean-up is
easy. On the contrary, obtainin~ and maintaining reliable data is
~erhaps the most difficult task ~nvolved in any form of
~nformation modeling. The difficulties are in:
(a) the volume of data,
(b) the number of sources for the data,
(c) identifying the correct sources.
with data coming from more than one source, quite often
inconsistencies appear. However, when there is only one source,
the ability to cross check against another source is not there,
and invalid data may very likely be accepted.
The most basic example of mUltiple sources for the same data
is in the definition of system-to-system interfaces. The complete
descri~tion of a system-to-s¥stem interface will include
commun~cation protocols, med~a type and Characteristics, volume of
data, frequency of data, and more.
The most simplistic need, however, is merely to identify
which systems are, in fact, interfacing and what data flows from
one system to the other. At times this is extremely difficult to
determine, especially in the case of planned systems or systems
under development or revision.
4
THE INFORMATION MODEL
The BSP/ISP methodology makes use of several interrelated
objects in defining the information model. specifically, these
objects and their data requirements are as follows:
Processes - Identified by the functional group number
and/or sequence number and process name and defined with one to
three paragraphs of narrative description, identification of
information classes created and used by the processes, critical
success factors relating to the processes, systems supporting
the process, parent and/or subordinate processes and
or9anizations with proponency and/or involvement with it.
(F~gure 4 on page 10 shows a detailed PSL syntax definition for
a DCSPER Process.)
Information Classes - Identified by the functional group
number and/or sequence number and information class name and
defined with one to three paragraphs of narrative description,
identification of parent and/or subordinate information classes, (
creating and using processes and organizations, and entities
making up the information class. (Figure 5 on page 11 shows a
detailed PSL syntax definition for a DCSPER Information Class.)
Organizations - Identified by the name of the organization
and showing the identification of parent or subordinate
organizations (if an¥), systems for which this organization has
proponency, informat~on classes used or created, critical
success factors relating to the organization, and processes for
which the organization has proponency or involvement. (Figure 6
on page 12 shows a detailed PSL syntax definition for a DCSPER
organ~zation. )
systems - Identified by the system acron¥ID and defined with
one to three paragraphs of narrative descript~on, identification
of parent or subordinate systems (if any), interfacing systems,
major inputs into and outputs from the system, points of
contact, and several items of specific environmental and
characteristic data. (Figure 7 on page 13 shows a detailed PSL
syntax definition for a System.)
Points of Contact - Identified by the office symbol and
last name of the point of contact and showing the identification
of systems for which the point of contact has responsibility,
type of responsibility, organization, complete mailin9 address,
and phone numbers. (Figure 8 on page 14 shows a deta~led PSL
syntax definition for a Point Of Contact.)
(
Entities (Input/Output flows) - Identified by the name of
the entity and showing the identification of parent and/or
subordinate entities (if any), associated information class(es),
and system(s) having the entity as an input or output.
critical Success Factors - Identified by the rankin9
sequence and name of the critical success factor and def~ned
with one or two sentences, identification of processes and
organizations which may have significant impact on the outcome
of the critical success factor.
5
Naming Conventions
strict naming conventions are necessary for the ISP objects
defined in the model in order to properl¥ identify and sequence
Processes, Information Classes, and crit~cal Success Factors.
Naming conventions are also essential to help separate and
categorize object names, and to distinguish between the several
ISP object types modeled using the same PSL object type. ISP
Processes, Organizations, and Systems are all modeled using the
PSL object "PROCESS". This is not a problem with version 6 of
PSL/PSA because of a sUbtypin~ capability. This model, however,
was constructed using an earl~er version, and the naming
conventions are an absolute necessity. Since this model covers
both the HQDA and DCSPER ISPs, some additional objects,
relationships, and naming conventions are required.
( lIQDA/DCSPER Information Model for PSL/PSA
As shown in Fi~ure 1 through 3, few of the object or
relationship names ~n the ISP model show any similarity to those
in th~ PSL model. Information modeling represents a somewhat
unique application of PSL/PSA, which was originally developed as
an ERA modeling tool. Some disregard for PSL/PSA terminology was
necessary in order to successfully map the BSP/ISP methodology
into PSL. However, "post editing" of the reports make this
transparent to the receiver who sees only the BSP/ISP terminology.
6
OBJECTS: Figure 1 shows the ISP objects, naming conventions,
and corresponding PSL objects used to model them.
Objects used in the Naminy Convention Modeled
ISP Information Model (pref x- and/or -suffix) in PSL as:
Functional Group DA-99- -GROUP PROCESS
HQDA Process DAP-99- PROCESS
HQDA Information Class IC-99- SET
HQDA Entity DAE- ENTITY
DCSPER Process P99.99- PROCESS
DCSPER Information Class 099.99- SET (
DCSPER Organization ORG- PROCESS
DCSPER Critical Success
Factor CSF-99- MEMO
(
system SYS- (or) SYSREF- PROCESS
DCSPER Entity (System IO) IO- ENTITY
Point Of Contact office-symbol (last-name) PROCESSOR
The "9"s indicate a sequence number or position in a
structural schema. "99" by itself represents a sequence number
while ".99" represents a sequence number within a higher
sequence structure.
FIGURE 1
7
RELATIONSHIPS: Figure 2 shows the relationships between the
ISP objects represented in the Information Model and co+responding
PSL relationships used to model them.
Relationships used in the PSL Relationship PSL
ISP Information Model Name Abre
Process/Organization Creates
an Information Class DERIVES DRVS
An Information Class is
Used by a Process EMPLOYED BY EPLD
A Major Input is Received by a System EMPLOYED BY EPLD
System Creates a Major Output DERIVES DRVS
Functional Group Decomposes into
HQDA Processes SUBPARTS ARE SUBP
HQDA Process Decomposes into
( DCSPER Processes SUBPARTS ARE SUBP
HQDA Information Class Decomposes into
DCSPER Information Classes SUBSETS ARE SSTS
System Interfaces another System TRIGGERS TRGS
Process is supported by a System UTILIZES UTLS
Organization is the proponent for
a System TERMINATES TRMS
Process or organization supports
a critical Success Factor SEE MEMO SM
HQDA Entity Decomposes into
a DCSPER Entity SUBPARTS ARE SUBP
Information Class is Linked to an Entity COLLECTION OF CLTN
Process Identifies an Organization
as its Proponent INCEPTION CAUSES INCC
Process Identifies an Organization
with Major Involvement INTERRUPTS INTS
Process Identifies an Organization
with Some Involvement TERMINATION CAUSES TERC
FIGURE 2
8
0\
BSP/ISP object and Relationship mapping into PSL Objects and Relationships
BSP/ISP terminology is at the upper left corner of the objects and in small
print on the lines representing the relationships. PSL terminology is shown at
the lower right of the objects and in large print on the relationship lines.
Figure 3
Des PER PRO C E S S
DEFINE PROCESS P_ ° _ -_ _ process~name. _
DESCRIPTION;
FULL NAME
spelLed out full name of the process
*****************************************************************
- - brief narrative description of the process - -
PART: DAP-_-_HQOA-process-name'----;. parent process
UTILIZES: SYS- system-acronym supporting
SYS----system-acronym'----- system(s)
SYS- system-acronym'- ;
(
EMPLOYS:
0=.=-
D
D
- •- -
• - inf·ormation-class-name
=information-class':name:=,
- information-class-name
-.-
;
I information
class(es) used
DERIVES: D_o_- _fnformation-cLass-neme_ _ ,. information
D_o_- _information-cLass-name_ _ ; class(cs) created
SEE MEMO: CSF-
CSF- =-
- CSF-name
-CSF-name--------;
critical success
tactor(s) which apply
INCEPTION-CAUSES:
ORG- organization-name' _ proponent
ORG- organization-name. _ organization(s)
INTERRUPTS: ORG- organization-narne _ organiz8tion(~)
ORG----organi zat ion-name with major
ORG-==orgsnization-name---- involvement
TERMINATION-CAUSES:
ORG- organization-name organization(s)
ORG----Organization-name·---- wi th some
ORG-==organization-name _ involvement
FIGURE 4
10
Des PER I N FOR MAT ION C LoA S S
DEFINE SET D. information~cl8ss-name ;
----
DESCRIPTION;
FULL NAME
spelled out full name of the information class
*******************************************************************
- - brief narrative descdption of the Information class - -
SUBSET: IC-
- -- HQDA- informat f on~class·n8me_; parent information class
(
COLLECTION: 10- entity-name entities
10- entity-name connected
10- entity-name to the
,.
10- entity-name Information
10- ent f tv· name class
EMPLOYED: ORG-______organization-name I organization(s)
ORG- ________organization-nome & process(es)
ORG- ________organization-name which use the
P -
P- • - _process-name
_process-name information class
··- --
P= - _process-name ,.
DERIVED: ORG- ___organization-name organizatfon(s)
ORG-_______organization-name &process(es)
ORG- ______organization-name which use the
P
p- ··-- --
_process-name
_process-name
information class
P-
·- - _process-name ;
FIGURE 5
11
Des PER o R G A N I Z A T ION
DEFINE PROCESS ORG- ,organization-name, _
PART: ORG- organi%at ion-name _ parent organization
TERMINATES: SYS- system-acronym system
SYS----system-acronym'------ proponency
SYS- ~system-acronym, 1
EMPLOYS: D
D
•
• =-
-
information-class-name
:information-class-name==,
I
D_"_-_information-class-name_ _ 1
information
cless(es) used
DERIVES: D_"_-_;nformation-class-name_ _ , information
D_"_-_information-class-name_ _ 1 cless(es) created
SEE MEMO:
ON-INCEPTION-OF:
CSF-
CSF- =
- CSF-name
-:csF-name--------1
critical success
factor(s) which apply
P • - process-name _ - proponent
p=. =-
p-" - - - process-name
=process-name
_
;
for these
processes
INTERRUPTED: P • - process·name _ major
P - "---process-name involvement
P .=-
p-" - -- process-narne-------
:process-name 1
in these
processes
TERMINATION: P • - process-name _ some
p-" - -- process-name _ involvement
p-" - -- process-name _ in these
P=.=-:process-name i processes
(
FIGURE 6
12
s YS T E M
DEFINE PROCESS SYS- system-acronymL......---;
DESCRIPTION;
FULL NAME
spelled out full name of the system
*******************************************************************
- - brief narrative description of the system - -
TRIGGERS: SYS-_ _system-acronym interfacing
SYS-_ _system-acronym ·•
EMPLOYS: IO- ent; tv-name major
IO:- entity-name ·•
DERIVES: IO- entity-name major
IO- entity-name ·•
UTILIZED BY: P
P- -
.. - process-name processes (
- - - _process-name ·•
TERMINATED: ORG-_ _organization-name proponent
ORG-_ _organlzation-nsme ; organizationCs)
ASSERT: _office-syrrbol_- {_lastname_} PROPONENT POC,
_office-syrrbol_-{_lastname_} ARA POC;
ATTRIBUTES ARE:
SYS-STAT 'CURRENT/PLANNED',
PROG-LANG 'LANG:
COMMO I
,"'I"'MM=p",nr--------...., - - - - - - - -
IMP/IMMP-NO
HOST-LOC
, -- ,
HARDWARE
MDEP-NO 'MDEP# - - i ,
OS ·OS:
DBMS 'DBMS-:":---------------, ~ l
KEYWORDS ARE: 'PRE-MOBILIZATION',
'MOBILIZATION' ,
, DEPLOYMENT' ,
'EMPLOYMENT' ;
PERFORMED BY: _office-syrrbol_- {_lastname_} ,
_office-syrrbol_- {_lastname_} ;
FIGURE 7
13
POI N T o f CON T ACT
DEFINE PROCESSOR _office-synbol_-{_lastname_} ;
DESCRIPTION;
full mailing address
of the
pot nt of contact
in address format
(to include zip code)
,.
ASSERTED BY: SYS- system-acronym'----_ _ TO BE POC FOR ARA;
ASSERTED BY: SYS- system-acronym,-_ _ TO BE POC FOR ARA;
ASSERTED BY: SYS- system-acronym,-_ _ TO BE POC FOR PROPONENT;
ASSERTED BY: SYS- system-acronym,-_ _ TO BE POC FOR PROPONENT;
ATTRIBUTES ARE:
AUTOV-PHONE '999-9999',
( COM-PHONE , (999) 999-9999',
FAX-PHONE '(999) 999-9999',
, ,
POC-NAME ---------------, :,
ACTIVITY
FIGURE 8
Output Pl'oducts
Because there is so much interrelated data collected in the
ISP Information Model, the possibilities for extracting
information from it are only limited b¥ the imagination. There
are, however, several basic re~orts wh~ch are standard to the
BSP/ISP methodology, all of wh~ch can be produced by PSA.
For each HQDA Functional Group: A listing of all HQDA
Processes subordinate to it and all DCSPER Processes
subordinate to each HQDA Process.
For each Process (HQDA and DCSPER): A summary showing
the process name as used in the model, the process name fully
spelled out, the description of the process, the information
classes used by the process, and the information classes
created by the process. Additionally, for each DCSPER Process
the summary includes the organizational proponency and
involvement levels.
For each DCSPER Process: A listing showing the systems
which support it.
For each Information Class (HQDA and DCSPER): The
description of the process.
For each HQDA Information Class: A listing showing the
DCSPER Information Classes subordinate to each.
14
Matrix reports showing the Process usage and creation of
Information Classes, one for HQDA and another for DCSPER.
A matrix report showing the Proponency and involvement
levels which the DCSPER Organizations have with each Process.
A matrix report showing the DCSPER Processes and Systems
and indicating which System(s) support each Process.
In addition to the basic BSP/ISP outputs some additional reports
are beneficial.
For each System: A summary showing the System name as used
in the model, the System name fully spelled out, the description
of the System, the major inputs to the System and major outputs
from the System, various characteristic data about the System
and its environment, and a collection of information about the
System's points of contact, to include: name, mailing address,
phone numbers, and organization.
A consolidated Points Of Contact (POC) list: showing the
name, office symbol, and phone numbers for each system POCo
A consolidated system characteristic list: showing the
system acronym, operational status, operating location, (
hardware, operatin~ system, communication protocal(s) used,
DBMS, and programm~ng language for each system.
A matrix showing the'systems and major inputs/outputs
indicating which system(s) produce and which system(s) use each
of the inputs/outputs.
Additionally, several other reports can be generated to
help purify the model and assist in architectural analysis.
CONCLUSION
Lessons Leal'ned
1. The information model must be maintained in an automated form
in order to keep pace with constant changes in functional
responsibility, organizational structure, and system environment.
2. Other, off-line, techniques may produce more attractive
results than can initially come from an automated tool. However, in
the long run the consistency and the ability to recreate the
automated tool output products totally outweigh the false beauty of
products derived by other means.
3. "Canned" macro generation of report packages can save
enormous amounts of time in the creation and tailoring of specific
output products. Canned macro "post-editing" of PSA reports is also
an easy and consistent way to isolate the end user of the ISP
products from confusing terminology.
4. The "sub-typing" capability of PSL/PSA version 6.0, will
allow objects to be named, referred to, and reported using the
terminology desired, Le., "System" to be called a "SYSTEM" and a
"Point Of Contact" to be called a "POINT OF CONTACT".
15
5. Another META Systems product, Report Specification
Interface (RSI), allows reports to be generated showing the
appropriate information model objects and relationships directly.
6. While processes and information classes may be of interest
at higher levels of an organization, system interfacing and system
characteristics are much more important at the lower levels.
7. There is a general lack of interest shown in sUbmitting
data for what could be (and should be) a meaningful and useful
information model. There are two main reasons for this:
a. Data calls (requests for specific data from
subordinate organizations) are all too often one-way streets.
The information is generally useful only to the hi~her level
organization which commissioned the study in the f~rst place.
b. The information, particularl¥ information on
developing systems and changing organ~zational responsibility,
is quickly out of date and may be obsolete even before it is
pUblished.
As a result, information models, for all their required
effort, tend to become bookcase fillers or door stops. One reason
why weak or inconsistent data may be received is the difficulty in
identifying the correct sources for reliable data. Roles may vary
from system to system, process to process, and organization to
organization. Another is actually getting the correct information
from the source. Some of this is because of the individual
personalities. variations in personal experience, level of
cooperation, and level of interest, as well as personnel turnover,
are also important factors. Some is because of the degree of
familiarity which the source has with the SUbject matter involved.
But most of the problems are encountered because of apathy on the
part of the suppliers of the data.
lIow can you ovm·come these difficulties?
Recommendations
1. Start early with an automated model and keep it updated.
An information model is like housework - it's not hard when you
keep it up an a regular basis, but when you let it go, everything
becomes a mess.
2. For organizations hiring a contractor to establish an
information model: Insist on the contractor maintaining all of the
ISP data within an automated tool, and monitor the compliance of
the contractor with this requirement.
3. For contractors performing BSPjISP studies and producing
ISPs: Actively use, and advertise the fact that you use, tools
capable of directly generating all ISP output products from a
logically single data base.
4. Get information back to the people who submitted the data
in the first place in a timely enough manner that it is useful.
5. Produce several smaller packages of information rather
than one large package of several hundred pages. A few up-to-date
references are far better than a single, large, obsolete one.
16
6. Put products out in soft format and/or have them available
via E-mail or bulletin boards.
7. Require that requests for project funding identif¥ how the
project will fit into the overall master plan and, specif~cally,
which processes will be supported.
Cm'l'mIt Status of the InfOl'nmtioll Model
Information from the DCSPER ISP database is now periodically
extracted and formally sent to various responsible organizations for
review and update, As responses are received, they are consolidated
and applied to the database,
Various extractions from the Information Model are now
distributed throughout the Army personnel community, and the PSL/PSA
database is becoming recognized as a valuable tool for analyzing
system-to-system interfaces and tracking overall system architecture (
development.
ACKNOWLEDGMIlNTS
It would not have been possible to write this paper without the
technical, functional, and editorial assistance and moral support and
encouragement of the following people: Fred Bock, Gene McGrath, Jim
Holt, John Hodges, C, Bresser, and Sonja McDaniel. My most sincere
thanks.
(
17
(
.(
(
l
,
I~
-> ->
Th___ ------>
I
. y _ ~ _ _ _
=~gg~:':h:_~:~~"G '--- '---
I
,, ""
,, :
I
... "
" ", I
a"
mz
J 1-11
~
~ m
z~~ mz
~~o u
I C!III. II " £
I
~~
"l!1
" UIIIE"; I-Q:>1:Qlt I-l¢
, II 1:lXtClt U:J"Q(D¢ I !til
" Z I I I I (lIUH1:1:lL ""¢:J
" II" 1II~~b1 1111111 II I111 ~
" • 1L HI Z ZZ 1111 lIlIlIlilItlllltil mill 1: IUDlIIllIlI I
" E. U ¢~ III til ~ D 00 ltlL lIlIlIlI~lIlIU IIl1zzmt HltlXlXlX II
"" .« III lilt 1-111 IIl1lLlIlX til 1-1-1-1-11111111 CQQQCQC( Q(lIIlX1:1 tWbllIIlII1I III
~ Willi IIQ.~O IIlL HU~HlL.1I liZ ZlililIlIlXlLlX IIIl1 II I I I I 11I1I1Lal~lLU IIlLllllLlXlI(Q
", • lIHIIC("'U:"'QIX:>III:IIUI:I:H(~¢HIH»»lLllIlI(H~a:a:a:a:a:a:a:a:(UUII"'W"'III1HQQQQIX ... U:l
,, •~ U-££'~~~J~("£mm~~(>Q£~~mOMM~i~OO~QQ£t~~···~·UUM.MOO~.U """""I~~
(~(( ((~(.UUUUUQQQQ~~.m".xxx £££ZOOO ~~~~LLLCCCCClc~ •••• mm ••• ~
" 1III111II111111I1111I111I11 1111111 1111111111111111111111111
"" .11.11.11 ••••••••• 11.111 ••••••••• 111111.11 •••• 1111 •••• 1111 ••••••••••••••••••
, »»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
" .11 ••• 11 ••••••••••••••••••••• 1111.1111 •••• 11 ••••••••••••••••• 11.1111 ••••
P.1_.1-~V-KANNXNO-QOALa/D8J 'r'----:::~~::::~~r'- - ; : T '--::;:--,'-'----,',--r
•• l --r'----r'--::;:--,'-:;;-l',--r'----r'--;;--r'-
•
~I
P.1a.2-DEV-~-HGT-POL/OUXD
P.1 . . .3-~V-PLANNXNG-POL/guXD
~1a.4-DEV-ACCN-POL/OUXD
P~1a~~-DEV-MANPRXNT-POL/BUXD
• • •
P.1 ...6-DEY-TNO/D~/BUXD
P~1a.7-D~Y-DXaTR-POL/GUXD • •
••
~
PG1 ...B-DEY-BU&T-PQL/QUXD
PG1 a m9-DEY-TRANQ/SEP-POL/GUXD
pe1_ 1GJ-DEY-PERS-P'LAN8
P.1 .. 11-PREP-P~-CONT/JT-~ND
P.1 .. 12-Dli.Y-THIL-ARt1V-MP'R-~
P.1_ 1:s-ACCOt'F'--.v:"R-PROQ-POf'I
P.2_.1-H&~~-.uDOET-EXEC
P.2 .. G2-MGK-ACCEU8-8UDQET-EXEC
.:+_.
• •
• - •
•• • ••
•
•
PG2 . . .3-HeK-XNDXY-ACCT
PG2_-.-KVAL-ACCN-EFF
P.2
P.2
~DT-auRVEva
-CDT-ANALVaX.
P.3 .. _1-eDT-AUDXT.
~~a.2-MGK-X~D-RE&OUftCE.
~g:~~DII:~~~~~~.,cu.
~~ 1-~-HPft-POftTX~-TAA
••
-
••
• :.1:-
••
•••
..J - ... -.k=.....
•
.-
•
.... ..
• • •
~ .. -
••
• ••
...I .
~.4
~.4 ••
2-~TH-FDRCE-RKQ
3-MOK~-RQHT-.V.
• ., , 1--:: _-: •
• •••
--
P.4 .. ~K-eXY-P08XTXON-HGT
P~ .. .:I-Dto:Y-t1f""1It-prQRCK-.TftUC-X.....
P.~ 1-eDT-RK.aARCH • • • •• •
,:: !::: In·-
P.~ 2-DCV~.-t-ftOC-P'LAN
P.~ .. G3-Fa~~R-DuD.
c. • •• •
•• -
P.~ . . .4-DEV-N r FtOCS/.uDCII • •
P.~
P.~
.. _~D£Y ACCN-PROC/8TD.
P~_.6-ACCKBa-PKft8
pg~_.7-t'lO_P&:RII
..
_B-MONXT~AT-ACQ-PftOG
PG6 .. _1-FCST-TOT-Aft-XNXT-TN-RQT
P • • _.2-D~V-TOT-Aft-XNXT-TN-~
P.6_.3-MO~-ARHV-%N%T-TRNG-PROG
1""---
:·1 :
--' --
I· I~ - I
• •
•••• • -
! ••
1
pg7 .. G1-DKT-uNXT-~%-PER&-REPL
P.7 .. ~2-DEY-PKR.-D%&T-PL/PROG.
P.7 ...3-VAL-HXL-PKRa-RQN.
P.7 .. ~4-Aa8XON-MX~-PERa
P.7
P.7
~HBE-eXVXL%~T
-HOVE-PER. •
P.7 .. _7-HOE-XND-XLVL/RED.T/D8T
p.7 ... e-DKY/XM~-UNT-MAN-.VB-P.
P.7 .. ~-MOVE-C0HE.XVK-ELK~.
p~e ... 1_MONT-PERa-RDv-aTAT/UNT.
P.B .. _2-MGE-PERS-STR
P.B . . .3-HQ~-PERa-.Ec/aRTV-cLKAft
P • • a.4-PROY-COMHUNXTV-gpT
p.a... ~-HGK-CAauALTV
Pt1J8 a ".-MGIi.-NAF
pgU __7-HGE-COHP/.KNEFXT/Ii.NTXTL
p . e __ g - H Q ~ - C X Y X ~ X A N - C L A 8 a X F X C N
PGBa.9-HGE-CXY-CARKKR-PROdS
P8g .. 1 __ F c a T - P E F t . - P ~ - D E Y - R K Q
P.g .. 11-"QK-PRO~-DEY-~
P
P
12~-M%~-~ROHOT%DNa
13-"G.-"X~-PKft8-RKCLA• •
-+;
•• ••
-J.:--
...
• ••
P • • a14-DKV/HGK~XL-RKTENTXON
P . . . . 1~HG.-P~-~-~ •• •• •
....... 1..........-:-KJ1IP/~-ftaL.-~
P1
P1
1-HG.-T~-Pft088
2-DKt1O~ • • • ,.• • • I
- • •
-s-
i
OIl
~
..
...=
o
( =
L"
"~-
,~ ,
, ,
"
, H',
a
~'
10
/
/ eo
/ ,~
~~~··········!~~~i~~~~~~~",~"",,000~55~1=~~=~"g···0oooooooo·~~~tii~i~~~ • l
~~ii~""""""O" 0" 00.;.;••••••• 0 O·~t'O~~~~··I"=~C~~ /
~ ~~~~~~~ '0"t···=,~~ I I /
.~ •••••". • 1~·OOt=
100000"" tn,! M_ ••
• "I" t" o.~ ~ "!~ 0 I'"0
I I II I I I III I ~' a~~ ~.. ~ NO ~O D •• M / U
~. ~ ~·tO ~OOO~~~~~~~
=.,••• ~~~~. ~ ~.' / .,••••
/ I
'I =. •••••••••• ! 0000 • =~ = ="" ,"
~
"., •••••
'It
===== • I'
I I I I I
• ........... • ==== I I I I I I I I I I • "II / n•
/
, 0 ••
~ ar"W ~n5ro.~~ I I I I / ••
/
• I I o~ ~"~O i~=~ •I .."•• ••
•• •I / • ~
b~ !"I~ 11 >Illr /
o• ~g~• "t '~ I O.ON ~~ !' n / ••
,I I ' ~
=~'~ ••
• • /
/
"
"~
/
,•
/
/
""I
~ / --_.- . __ .
-
/
• AO • • RJiI
l l ........
l l ...........
• •• • .......
..• • • • • ....08-0
~l • &R£J> ..
~' • • I I • -~ ..........0
•• r • I ART"
I ...TRRII
.. l .. I I I AUTOR:KP
• :4 ~'" I • •• ••• ••
l I .." (
I ,• I C&RQ'Z',&,TII
•• C:J:VP.RIilIXMB
..1..I .....o_.....
•j •• • • • • O.MX8
• I 0 ••0 •
DAO• • a
I
- • • •• • D ...........
D ..........
DVZ. (
I • I •• 80A8
_RAIl
0.:1 . . .
•• • •••• • • • ••• •••• •• • • ••• •
• I
•I •••• ••••• --
•• I .... JOZ.
I x.'I'a'l'oanc-YOL
l • xa'l'8'rOM1I:-R:.QtJ:.IJ'Z'
•I • ~, l l
1-' • • • K ..... TO. .-RaTAXM
• I xa.... TO. .-RM8
_PRII
• • • • • . . . RII
1«)• • • 1UiI
• • • • MOII~PJliil
• , • .. I • .... OD....
• • ODxa
: ••• 0_
• ••
• • • •• • • • • •It-I)IJII-AO'T-.)fL
..It-Da:a:-&.c'r-or.,
I-t" • ••• • • ••
i. I ..a-DIiUI-8UOO.'Z'
.~ ~. •••• •
•
I • I • • Jt-Da:8-C%~OR.8
• •R-DIiI8-J:DM8
• l • • • • • • • •-DII8-KA.DXa.:
..a-DIiI8-UOIiMAM'
I •• I . . .-1)11111- .......
I I• I I •
• •• • • •-DIlII-I\O-.ML
••Jt-D".-RO-orr
..JUlAO •
I • .--
.... ••
I • ""....ItOOPDIiI
I I _ 0 .......
• ... I • • Ra: • • •. , .
• • •
, • . . .T ..... (
I-- a._
I • • ..........
ltOa.MIiiI
I.
• • • I RO'l'C-aAaI
I
:t- •••
• • • • • ..... • •• ........ RRII
• IIOZPlrlU8
• a XDP.IUiiI-2-.A.1I ZMII (
• • • • •• • IIZDPaRJiI-a
fo;.t". 1-'" • .~ . '- ...-::.. -
• I ...;. .XDP.R8-S-TX.R-XXX-V1
• •
~- • • • ~~ ~ I ~ • aXD• •R.S-AJUf'CI
•• ••• • • •••• .XDP.R8-Va:.&R
I I ••I .aT•
I
••••
•
• •
•••
• ••
••• •• •••
• .'Z'. . . . .- .
'Z'.&.6.MRXII/MAOD.
......
I II • II .~ 'Z'~D.
• I T~ • •
If·.. • •• • I
•• •• • • I II
.-.. .. .
,
I
I "H.
~~~ ••••••••• ~!~'~"~==""""""'000=55~la~~~~HgR;R~~~~nnnnnl~~~~i~~i~~t • f I RlI'C
~~ii~HHHHHHnl S H nn=g=g==.gRg.~~~ ll O~~~ ~~~~t.~IH=~~~~ H I k,'
!~~~~~H~ t RI ~nnt HIH I I I 'f'
I I I I II II I I . ! ' ~
=~ •""". n,~ RI"
' • , Ht. == "=. tH ~n~~ ~ ~O =~••~ ~ I' I fU
~ ~~~~ a·.·· R~ ij 8·b HH H I ~H'
==== ~ I
I
'H., =..n~R~=. I'I~ ==t~~ ..t~~~~~~~~~~
'" 11111
~~.~.~... ·
II II II I I I I
=~ n ,
"H~
f I
l~,
~ ~"5rn.t~ IIII = I
I I
Qi~ UW n~ ~Hr 1U5 ~~
.
HO
~
H I
...
b~ !HU 11 ~ I ••
'~ I ORO. ~~ a
~. • I 11
•~ ~g~•I tH f f I ,
' ,
=~'~ I.
H I f f
,HI
H ~
I
I
.I
H I
I I
~ I .- ... -I• •
• I
I AC:r.XPIl
~ .....
.a.J:RT.M8
I Atnul
I "'"uv..
1lI0:r,P-QQPR:l
OMO. . .
co.,n:a-p''&
OP.....
ORa-a
••
oor"-TPM.J:a
( i , ow-rORCOW
I)OX:l
I I D • • R.8
D • •O'l'-ASlII.TII
I I D.....,
'"''
• I • DOD-"~
/~
P...,,,
~
.... ..
..ORJ)x .... - P / . . .
110. . . .
I %Olt
I :lDAO.
I %'1'0.
J ........
• .1011'1'% •
LJ:M'AP8
..- •
I MOII'-"P
I MOP
IIIT.IIP
...,..,
I MOXO
O.....-.UJ>G.T
I . 001Um
o ...-opn.
0"---2
• • "-1"1'011.
PMAD
I P-
poao
I P •••
I R4PZD.
"'T"'-
• ......
IIORTII
....T
•••
II'II'...-r:r._.
•
I
I
I
....
IITA.R.O:lpa
8TAROJ:PII-R
II •• • I • I I 'I' A.&J) II "V"1" A.&J) a
'I'.... D ..
TO.
I f "1".... D.
,
~ ~ ~ ~
PSA Version A5.2R5M Feb 24, 1989 13:12:12 Page 4
MTFAA_MASTER PLAN
System Descriptive Inrormation
+--------------------------------+
I CURRENT/PLANNED !
!--------------------------------!
I 8ASELINE/OBJECTIVE I
!--------------------------------!
! USATRADOC INSTALLATIONS !
!--------------------------------!
10-ACADEMiC-DATA --------------!
10-CLASS-SCHED-DATA -----------! SYS-AIMS !-
!-
10-ACADEMiC-DATA
iO-CLAqS-SCHED-DATA
10-PERSONNEL-DATA -------------! DEC VAX 11/750 !- 10-CLASS-UTILIZATION-DATA
10-POI-DATA -------------------!
10-TESTING-DATA ---------------!
OS: VMS
DBMS: INGRES
!-
!
10-COURSE-SCHEDULES
IO-TRAINING-OATA --------------! LANG: BASIC+, "e" !
! DIAL-UP / DON (FUTURE) !
+---------------------- --------------------+
! FULL NAME !
! AUTOMATED INSTRUCTIONAL MANAGEMENT SYSTEM
! ************************************************************************
!
! AiMS IS AN INTERACTIVE TRAINING MANAGEMENT SYSTEM TO BE UTILIZED BY
! SCHOOLS AND TRAINING CENTERS iN THE ENROLLMENT, TESTING, GRADiNG,
! SCHEDULING, AND GRADUATION OF STUDENTS. AIMS PROVIDES SUMMARY DATA TO
! HQ TRADOC AND CLASS RESERVATIONS TO HQDA THROUGH ATRRS.
!
+---------------------- --------------------+
!--------------------------------!
! MDEPH TSPU !
!--------------------------------!
! IMMPH 57-85-400 !
+--------------------------------+
Supports: PRE-MOBiLIZATiON
MOBI L1ZATION
."-,' • •"l' _ •• . ~ -.~ .
c"~
c-'
PSA Version A5.2R5H Feb 24, 1989 13:12:40 Page 5
HTFAA_HASTER_PLAN
System Interaction
SYS-AIHS
SYS-ATRRS (Interfacing System)
SYSREF-FORDIHS-P/BS (Interfacing System)
SYS-SIOPERS-3 (Interfacing System)
SYS-ROTC-HHS "( Inte rfac Ing System)
SYS-APDS-C (Interfacing System)
SYS-SIDPERS-2-ASIHS (Interim Interface)
SYS-RECBASS (Interim Interface)
SYS-STRAMS-E (Interim Interface)
SYS-SIOPERS-3-TIER-III-V1 (Interim Interface)
P03.02-HGE-INFO-RESOURCES (Supported Process)
P03.03-CREATE/HAINT-PERS-RCDS (Supported Process)
P06.01-FCST-TOT-AR-INIT-TN-RQT (Supported Process)
P06.02-DEV-TOT-AR-INIT-TN-PROG (Supported Process)
P06.03-HGE-ARMY-INIT-TRNG-PROG, (Supported Process)
::s-
~
~" ~
<.......
~ ~
PSA Version A5.2R5M feb 24, 1989 13:13;37 Page 6
MTFAA_MASTER_PLAN
System Point-Or-Contact Information
SYS-AIMS has ATIC-IMI!GOUGH! as the ARA point-or-contact.
2 SYS-AIMS has ATTG-M!BUTCHER! as the PROPONENT point-or-contact.
1 ATIC-IMI!GOUGHI
Mailing Address:
COMMANOER
U.S. ARMY TRAINING AND DOCTRINE COMMAND
ATTN: ATTG-M (MR. GOUGH)
FT MONROE, VA 23651-5000
AUTOV-PHONE , 680-2751'
COM-PHONE , (804)727-2751'
FAX-PHONE , (804)727-3614'
ACTIVITY 'USATRADOC'
POC-NAME 'MR. DON GOUGH'
2 ATTG-M!BUTCHERI
Mailing Address:
COMMANDER
U.S. ARMY TRAINING AND DOCTRINE COMMAND
ATTN; ATTTG-M (MAJ BUTCHER)
FT MONROE, VA 23651-5000
POC-NAME 'MAJ BUTCHER I'
AUToV-PHoNE '680-2780'
COM-PHONE , ( 804 )727-2780'
FAX-PHONE , (804)727-3614'
ACTIVITY 'USATRAoOC'
l-r>
<:;-;