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. 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)
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.
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.
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.
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.
INTENT PSL/PSA ( ( ( (
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 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. ( ( ( (
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.
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. ( (
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.
OBJECTS: Figure 1 shows the ISP objects, naming conventions, and corresponding PSL objects used to model them.
Naminy Convention (pref x- and/or -suffix)
Modeled in PSL as: -GROUP Objects used in the ISP Information Model Functional Group HQDA Process HQDA Information Class HQDA Entity DCSPER Process DCSPER Information Class DCSPER Organization DCSPER Critical Success Factor system PROCESS PROCESS SET ENTITY PROCESS SET PROCESS MEMO PROCESS ENTITY ( (
SYS- (or) SYSREFDCSPER Entity (System IO)
IOPoint 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.
DA-99DAP-99IC-99DAEP99.99099.99ORGCSF-99
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 ISP Information Model Process/Organization Creates
an Information Class An Information Class is
Used by a Process A Major Input is Received by a System System Creates a Major Output Functional Group Decomposes into
HQDA Processes HQDA Process Decomposes into
DCSPER Processes HQDA Information Class Decomposes into
DCSPER Information Classes System Interfaces another System Process is supported by a System Organization is the proponent for
a System Process or organization supports
a critical Success Factor HQDA Entity Decomposes into
a DCSPER Entity Process Identifies an Organization
as its Proponent Process Identifies an Organization
with Major Involvement Process Identifies an Organization
with Some Involvement Information Class is Linked to an Entity COLLECTION OF PSL Relationship Name DERIVES EMPLOYED BY EMPLOYED BY DERIVES SUBPARTS ARE SUBPARTS ARE SUBSETS ARE TRIGGERS UTILIZES TERMINATES SEE MEMO SUBPARTS ARE INCEPTION CAUSES INTERRUPTS
TERMINATION CAUSES TERC
PSL Abre DRVS EPLD EPLD DRVS SUBP SUBP SSTS TRGS UTLS TRMS SM SUBP CLTN INCC INTS 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.
P R O
spelLed out full name of the process ***************************************************************** - - brief narrative description of the process -
DAP-_-_HQOA-process-name'----;.
parent process supporting
system(s) information
class(es) used information
class(cs) created critical success
tactor(s) which apply proponent
organization(s) organiz8tion(~) with major
involvement organization(s) wi th some involvement 0D=•.= -inf·ormation-class-name
I =information-class':name:=,
CSF-=--CSF-name CSF- -CSF-name--------; organization-name' organization-name. _ _
ORG-==orgsnization-name---
I N F O R
MAT
I O N
C LoA
S S
DESCRIPTION; FULL NAME spelled out full name of the information class ******************************************************************* - - brief narrative descdption of the Information class - SUBSET: COLLECTION: EMPLOYED: DERIVED:
HQDA- informat f on~class·n8me_; parent information class
( . , I . , ; entities connected to the
Information
class organization(s) &process(es) which use the
information class organizatfon(s) &process(es) which use the
information class IC-- -
o R G A N I
Z A T I O N D • =--information-class-name I D • :information-class-name==, D _ " _ -_information-class-name_ _ 1 =- CSF-name
-:csF-name--------1
P - "---process-name
.=p - " - -- process-narne------
p - " - -- process-name p - " - -- process-name P=.=-:process-name _ _ _ _ _ ; 1 i parent organization system
proponency information
cless(es) used information
cless(es) created critical success
factor(s) which apply - proponent for these
processes major involvement in these
processes some involvement in these processes ( DEFINE PROCESS
SYSsystem-acronymL......---;
DESCRIPTION; FULL NAME spelled out full name of the system ******************************************************************* -- brief narrative description of the system -( l SYS-__system-acronym SYS-__system-acronym IOIO:IOIOent; tv-name entity-name entity-name entity-name P . - process-name P- .-- -_process-name
ORG-__organization-name ORG-__organlzation-nsme · • · • · • · • ; interfacing major major processes proponent
organizationCs) _office-syrrbol_- {_lastname_} PROPONENT POC, _office-syrrbol_-{_lastname_} ARA POC; 'CURRENT/PLANNED', 'LANG: I ,,"'I"'MM=p",nr--------..,.. - - - - - - -
- - , 'MDEP# - - i , ·OS: 'DBMS-:":---------------, ~ s Y S T E M TRIGGERS: KEYWORDS ARE: 'PRE-MOBILIZATION', 'MOBILIZATION' , , DEPLOYMENT' , 'EMPLOYMENT' ; PERFORMED BY: _office-syrrbol_- {_lastname_} , _office-syrrbol_- {_lastname_} ; 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: ASSERTED BY: ASSERTED BY: ASSERTED BY:
SYSSYSSYS
SYSATTRIBUTES ARE:
AUTOV-PHONE COM-PHONE FAX-PHONE POC-NAME ACTIVITY system-acronym'----__ TO BE POC FOR ARA; system-acronym,-__ TO BE POC FOR ARA; system-acronym,-__ TO BE POC FOR PROPONENT; system-acronym,-__ TO BE POC FOR PROPONENT; '999-9999', , (999) 999-9999', ,'(999) 999-9999',
, - - - - - - - - - - - - - - - , :,
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.
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". ( 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?
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. 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.
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. ( =~gg~:':h:_~:~~"G I ", " , " " " : I I '--
II
Z P.1_.1-~V-KANNXNO-QOALa/D8J 'r'----:::~~::::~~r'--;:T'--•::;:--,'-'----,',--l r--r'----r'--::;:--,'-:;;-l',--r'----r'--;;--r'• ~I •
• • • " .:+_.
• • • • • • -• :.1:- •••
• • ..J • • ~~ 1-~-HPft-POftTX~-TAA ~.4 2-~TH-FDRCE-RKQ ~.4••3-MOK~-RQHT-.V.
P.4.. ~K-eXY-P08XTXON-HGT • P~.. .:I-Dto:Y-t1f""1It-prQRCK-.TftUC-X.....
P.~ 1-eDT-RK.aARCH • • P.~.. _~D£Y ACCN-PROC/8TD. I n · P.~ 2-DCV~.-t-ftOC-P'LAN P.~.. G3-Fa~~R-DuD. • P.~...4-DEV-N c. r FtOCS/.uDCII P~_.6-ACCKBa-PKft8 •• • pg~_.7-t'lO_P&:RII 1,:":"!-::-:- --'- P.~.. _B-MONXT~AT-ACQ-PftOG
P ••_.2-D~V-TOT-Aft-XNXT-TN-~ :·1 : I· I I P.6_.3-MO~-ARHV-%N%T-TRNG-PROG 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 ~HBE-eXVXL%~T • P.7 -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
p.e __g-HQ~-CXYX~XAN-CLA8aXFXCN PGBa.9-HGE-CXY-CARKKR-PROdS P8g.. 1 __FcaT-PEFt.-P~-DEY-RKQ P.g.. 11-"QK-PRO~-DEY-~ P 12~-M%~-~ROHOT%DNa P 13-"G.-"X~-PKft8-RKCLA•• P ••a14-DKV/HGK~XL-RKTENTXON P .... 1~HG.-P~-~-~ • ....... 1..........-:-KJ1IP/~-ftaL.-~ • P1 1-HG.-T~-Pft088 P1 2-DKt1O~ • • -+; • • • • • • J.:• - •
• .-.•. ,•.
• • ... a" mz
~ J 1-11 UIIIE"; 1:lXtClt I I I I 1II~~b1
'--~ m z~~ ~~o muz I C!III. II " £ I-Q:>1:Qlt U:J"Q(D¢ (lIUH1:1:lL - • • - • •
• • • ...•.. .•.
• • •
• • - ...
-.k.=. ~.. .. . ., , • 1--:: _-:
••• • • •• •• • • •• • • •
! •• 1 •
-> >
I " " " I ~ ~ "l!1 I-l¢
I !til ""¢:J
~ • • • • • • • •
..I. . •
I - • • ~ , , " , H'
, ~'
..1.. •• I .. , I •• ••• • • • • l • •
I • • • • • I • l l •
I I • • ... I :tI.
•••
II •
I ~'
• I • • •• I • l 1-' •
• • I-t" I - .. • • I • j I I I I I • • • fo;.t".
• • • •• • ••• • • " •• ~ • I I
I I • • I • •
II • • • •
I • • • • • • • • •
I
• • l I I • I...•.
.~ ~.
• •
• i. • •
•• • • I I • .-• •
I II • • • • • • • • If·..
• • • • • ,
I
I • • •• • • • ~, • • • • • • •
I • • • • • • I • • • • •• •
• .
••.. .. . .~ ~~~··········!~~~i~~~~~~~",~"",,000~55~1=~~=~"g···0oooooooo·~~~tii~i~~~ ~~ii~""""""O" 0" 00.;.;•••••••'00 • O·~t'O~~~~··I"=~C~~ "0 • l 100000"" t • 1~·OOt= ~ ~~~~~~~ "t···=,~~ "I" t" o.~ ~ "!~ 0 I ' .~~. ••••••••••"~. n'I,! M~·_•t•O ~OI OI OII~ ~I~I~I~II~I~ I ~!' a~~~~~~~... ~=.N,O•••~ ~O=D~.'• • =M I I "., =====• I ' =•. ..•.•.••.•.•.•.•.•.•. • =00=0=0= • =~~ , 0 ."." ," 'It I I I I I I I I I I I I I I I "II "•• • ~ ar"W ~on~5r~o".~~O~ iI ~I=I ~I •I •• •• o• •~g~•I "tI b'~~ !I"I~O.O1N1 >~~Illr !••' •In ,I I ' =~'~~ • • • • I • • • • • ••• • • I •• • • • •• •• • • •• • .. l .. I • • l • •• • • / / / / /
/ .__ .
/ / / / •• •• .U, I n• •• • ~ • , • • ( ( ( / / /
/ / /
/ / /
/ / / --_..A..O..•..•.RJiI ........... ....... .A..U..T..O.R:KP .. oC&_RQ'Z',&,TII
.." C:J:VP.RIilIXMB O.MX8 0 ••0 • DAO••a D ........... -D ..........
DVZ. 80A8 _RAIl • •
I l l I • • • • •
• • I I • I • • I • I
• • •• ~ I I ~g~ t • H ,I I H H H I ~ I II • •• •• •
I
I I •
I I
I I I II II II IIII ~"5rn.t~
n~ ~Hr b~ !HU 11 '~ I ORO.
=~',~
I i I I .
I I
I I
• ~~~•••••••••~!~'~"~==""""""'000=55~la~~~~HgR;R~~~~nnnnnl~~~~i~~i~~t ~~ii~HHHHHHnl S H nn=g=g==.gRg.~~~ O~~~ ~H~~~t.~IH=~~~~ H • f =~ •!~"~"~~"~H.~ tn,R~ I R~I"nnt I I I I II' II•I,IH.t!.ll'== "HIH=t. ~n~~ ~ ~O =~• •~ ~I~' I I 'H =..~R~ 'I~ ==t~ t~~~~~~~~~~ ~ ~~~~ a·.·· R~ ij 8·b ., n =. I ~ ..~~.~.~... · ==== =~ H~
I
I
I
I
I .- ...
I
I 'f' fU ~H' .l~.., 1, 1.I •• f f I• • I 1I UII5I
~ ~~ IH.
~ I , ..
I I • = • • •
I
HH H .. n ,~ " f ~~ ~ HO H
I
I
I
I
I
I
I I
I
I
I I
I AC:.r...X.P.Il ~ .a.J:RT.M8 Atnul "'"uv.. 1lI0:r,P-QQPR:l OMO... co.,n:a-p''& OP.....
ORa-a oor"-TPM.J:a ow-rORCOW I)OX:l D••R.8 D••O'l'-ASlII.TII .D.O..D-".~.
D'"..'.'..,
/~ P...,,, ..ORJ)x .... -P/... 110.... %Olt :lDAO. %'1'0.
J ........ .1011'1'% • LJ:M'AP8 MOII'-"P MOP .II.I.T,...I,IP MOXO O.....-.UJ>G.T 001Um o ...-opn. 0"---2 ••"-1"1'011.
PMAD Ppoao P ••• R4PZD. "...'.T.. "'. ......T.
IIORTII ~ ~
System Descriptive Inrormation +--------------------------------+ I CURRENT/PLANNED ! !--------------------------------! I 8ASELINE/OBJECTIVE I !--------------------------------! ! USATRADOC INSTALLATIONS ! !--------------------------------! 10-ACADEMiC-DATA --------------! SYS-AIMS 10-CLASS-SCHED-DATA -----------! 10-PERSONNEL-DATA -------------! DEC VAX 11/750 10-POI-DATA -------------------! OS: VMS 10-TESTING-DATA ---------------! DBMS: INGRES IO-TRAINING-OATA --------------! LANG: BASIC+, "e"
! DIAL-UP / DON (FUTURE) +---------------------! FULL NAME ! AUTOMATED INSTRUCTIONAL MANAGEMENT SYSTEM ! ************************************************************************ !- 10-ACADEMiC-DATA !- iO-CLAqS-SCHED-DATA !- 10-CLASS-UTILIZATION-DATA !- 10-COURSE-SCHEDULES ! ! ! --------------------+ ! ! ! 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 ! +--------------------------------+
."-,' ••"l' _ •• . ~ -.~ . c"~
System Interaction
P06.03-HGE-ARMY-INIT-TRNG-PROG, (Interfacing System) (Interfacing System) (Interfacing System) "( Inte rfac Ing System) (Interfacing System) (Interim Interface) (Interim Interface) (Interim Interface) (Interim Interface) (Supported Process) (Supported Process) (Supported Process) (Supported Process) (Supported Process) ::s <.......
'MAJ BUTCHER I' '680-2780' , ( 804 )727-2780' , (804)727-3614' 'USATRAoOC'