AVIATION LOGISTICS MANAGEMENT INFORMATION SYSTEM
BUSINESS AREA ANALYSIS (BAA)
OPERATIONAL CONCEPT DESCRIPTION
Contract Number: GS11K95BJD0002
Task Number: N1J697008
Deliverable Number: 007
November 11, 1997
Version 1.1
Prepared for:
Commanding Officer
United States Coast Guard
Aircraft Repair and Supply Center (ALMIS Project Office)
Management Information Services Division, Building 63
Elizabeth City, NC 27909-5001
Prepared by:
OAO Corporation
7500 Greenway Center Drive
Greenbelt, MD 20770-3585
ALMIS Operational Concept Description
Table of Contents
1. SCOPE ................................................................................................ 1-1
1.1 Identification..................................................................................................... 1-1
1.2 System Overview ............................................................................................. 1-1
1.2.1 ALMIS Project Sponsor ............................................................................................ 1-2
1.3 Document Overview ........................................................................................ 1-2
2. REFERENCED DOCUMENTS ............................................................ 2-1
3. CURRENT SYSTEM OR SITUATION ................................................. 3-1
3.1 Background ...................................................................................................... 3-1
3.2 Objectives ......................................................................................................... 3-1
3.3 Scope ................................................................................................................ 3-2
3.4 Operational Policies and Constraints ............................................................ 3-3
3.5 Description of Current System or Situation .................................................. 3-3
3.5.1 Required States and Modes ....................................................................................... 3-4
3.5.2 System Components .................................................................................................. 3-5
3.5.3 Interfaces ................................................................................................................... 3-5
3.5.4 System Functional Requirements .............................................................................. 3-5
3.5.5 Performance Characteristics ...................................................................................... 3-6
3.5.6 Safety Requirements .................................................................................................. 3-6
3.5.7 Security Requirements............................................................................................... 3-6
3.5.8 Privacy Requirements ................................................................................................ 3-7
3.6 Users or Involved Personnel........................................................................... 3-7
3.7 Support Concept .............................................................................................. 3-7
3.7.1 Hardware ................................................................................................................... 3-7
3.7.2 Software..................................................................................................................... 3-7
3.7.3 Interfaces ................................................................................................................... 3-7
3.7.4 Operation and Support............................................................................................... 3-7
3.7.5 Training ..................................................................................................................... 3-7
4. JUSTIFICATION FOR AND NATURE OF CHANGES ......................... 4-1
4.1 Justification for Change .................................................................................. 4-1
4.2 Changes ............................................................................................................ 4-1
i
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
4.3 Priorities Among the Changes ........................................................................ 4-2
4.4 Changes Considered But Not Included ......................................................... 4-3
4.5 Assumptions and Constraints ........................................................................ 4-4
5. CONCEPT FOR A NEW OR MODIFIED SYSTEM .............................. 5-1
5.1 Background, Objectives, and Scope .............................................................. 5-1
5.1.1 Background ............................................................................................................... 5-1
5.1.2 Objectives .................................................................................................................. 5-1
5.1.3 Scope ......................................................................................................................... 5-1
5.1.4 Assumptions .............................................................................................................. 5-2
5.1.5 Constraints ................................................................................................................. 5-2
5.2 Description of the Modified System ............................................................... 5-4
5.2.1 ALMIS System Description ...................................................................................... 5-4
5.2.2 Required States and Modes ....................................................................................... 5-5
5.2.3 System Functional Requirements .............................................................................. 5-7
5.2.4 ALMIS Performance Threshold Values .................................................................... 5-8
5.2.5 ALMIS Server Performance Values .......................................................................... 5-9
5.2.6 Adaptation Requirements ........................................................................................ 5-10
5.2.7 Safety Requirements ................................................................................................ 5-10
5.2.8 Security and Privacy Requirements ......................................................................... 5-10
5.3 Users or Involved Personnel......................................................................... 5-11
5.4 Support Concept ............................................................................................ 5-12
5.4.1 CSCI Capability Requirements ............................................................................... 5-12
5.4.2 System Environment ............................................................................................... 5-17
5.4.3 Computer Resource Requirements .......................................................................... 5-19
5.4.4 ALMIS Maintenance Requirements ........................................................................ 5-19
5.4.5 Maintenance and Life Cycle Costs .......................................................................... 5-20
5.4.6 Process and Data Models ........................................................................................ 5-22
5.4.7 Design and Implementation Constraints ................................................................. 5-22
5.4.8 Personnel-Related Requirements ............................................................................ 5-23
5.4.9 Training-Related Requirements .............................................................................. 5-24
5.4.10 Logistics-Related Requirements ............................................................................ 5-24
5.4.11 Other Requirements ............................................................................................... 5-25
6. OPERATIONAL SCENARIOS ............................................................. 6-1
ii
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
7. SUMMARY OF IMPACTS ................................................................... 7-1
7.1 Operational Impacts ........................................................................................ 7-1
7.2 Organizational Impacts ................................................................................... 7-1
7.3 Impacts During Development ......................................................................... 7-2
8. ANALYSIS OF THE PROPOSED SYSTEM ........................................ 8-1
8.1 Summary of Advantages ................................................................................. 8-1
8.2 Summary of Disadvantages/Limitations ........................................................ 8-1
8.3 Alternatives and Trade-Offs Considered ....................................................... 8-1
9. NOTES ................................................................................................ 9-1
9.1 Terms and Definitions ..................................................................................... 9-1
9.2 Acronyms and Abbreviations ......................................................................... 9-1
Appendices
Appendix A.
Appendix B.
Appendix C.
Appendix D.
Appendix E.
Appendix F.
Appendix G.
Appendix H.
Appendix I.
Appendix J.
Appendix K.
ALMIS Software Life Cycle Management Plan ....................................................A1
BPWIN ALMIS IDEF0 Process Model ................................................................B-1
ALMIS Objectives Functional Correlation ...........................................................C-1
Prioritized Requirements Correlation Analysis .................................................... D-1
Cost Xpert Cost, Schedule, and Risk Reports ....................................................... E-1
ALMIS IDEF1X Entity Relationship Diagram ..................................................... F-1
ALMIS IDEF1X Entity Definition Report ........................................................... G-1
ALMIS IDEF1X Key Attribute Report ................................................................ H-1
ALMIS IDEF1X Attribute Definition Report ........................................................ I-1
ALMIS IDEF1X Relationship Report ....................................................................J-1
ALMIS IDEF1X Entity Relationship Cross-Reference Report ............................ K-1
List of Figures
Figure 5-1. Representative ALMIS Wide Area Network System Architecture ........................ 5-19
Figure 5-2. Maintenance Activities Broken Down by Category ............................................... 5-21
List of Tables
Table 5-1.
Table 5-2.
Table 5-3.
Table 9-1.
Table 9-2.
ALMIS Performance Threshold Values .................................................................... 5-8
Digital AlphaServer 4100 5/400 System Performance Values .................................. 5-9
ALMIS Server Environment.................................................................................... 5-18
Terms and Definitions ............................................................................................... 9-1
Acronyms and Abbreviations .................................................................................... 9-1
iii
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
1. SCOPE
1.1 Identification
The Coast Guard’s Office of Aeronautical Engineering is in the process of merging its two
logistics information systems, the Aviation Computerized Maintenance System (ACMS) and the
Aviation Maintenance Management Information System (AMMIS), into one Aviation Logistics
Management Information System (ALMIS).
1.2 System Overview
ALMIS will serve the logistics needs of the US Coast Guard Aviation community at 24 Air
Stations and at the Aircraft Repair and Supply Center (AR&SC), Elizabeth City, NC. As such,
ALMIS will be used to manage and document the activities of five major business areas:





Aircraft Maintenance (Organizational and Depot),
Flight Operations,
Supply (Organizational and Depot),
Procurement Management, and
Financial Management.
ALMIS will integrate the functions and expand the capabilities of the two current systems
(ACMS and AMMIS) and will be supported and maintained by Government employees and
contractor personnel. ALMIS data will be available via World Wide Web (WWW) and
Graphical User Interface (GUI) technologies to authorized users at the USCG Headquarters.
OAO Corporation’s Information Technology Division - East performed a Business Area Analysis
(BAA) and related service and analyses for ALMIS. The analysis documented the current and
proposed states of the USCG Aeronautical Engineering's two information systems: the ACMS
and AMMIS.
The functions required to perform this task included, but were not limited to, the following:









Systems Analysis of Legacy Software Systems,
Analysis of Hardware and Telecommunications Systems,
BAA,
Business Process Modeling,
Logical and Physical Data Modeling,
Business Process Reengineering/Business Process Improvement (BPR/BPI),
Software Engineering,
System Design, and
Database Design.
1-1
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
1.2.1 ALMIS Project Sponsor
The ALMIS Project Sponsor is:
Commandant (G-SEA)
United States Coast Guard
Office of Aeronautical Engineering
2100 2nd St., SW, Room 6204
Washington, D.C. 20593-0001
1.3 Document Overview
This document will provide a Software Life Cycle Management Plan (SLCMP) as required by
the ALMIS Statement of Work (SOW) in accordance the Operational Concept Description
(OCD), Data Item Description (DID) DI-IPSC-81430. The SLCMP is provided as Appendix A.
The ALMIS OCD will establish a blueprint for development of ALMIS, including:



System Development;
Post-Development; and
Integral Processes; including:
 Project planning and oversight,
 System design,
 Software design,
 Software quality management,
 Configuration management,
 Software and system tests, and
 Installation and testing.
The OCD includes a Life Cycle Cost (LCC) estimate by life cycle phase which was derived using
the Cost Xpert Cost Model. OCD activities were mapped from the activities listed in IEEE
Standard 1074-1991, “Standard for Developing Software Life Cycle Process.” This standard
features 17 processes and 65 activities. This OCD also includes an explanation of the use of the
Spiral Software Development Model as a basis for the SLCMP.
The contents of this OCD is as follows:






Section 1.0 provides an overview of the current and proposed systems.
Section 2.0 contains a list of documents referenced herein.
Section 3.0 provides a detailed description of the current system.
Section 4.0 discusses the need and justification for changes to the current system and
describes the proposed changes and their relative priority.
Section 5.0 presents a detailed description of the system concept.
Section 6.0 provides an operational scenario that illustrates how the proposed system will
be employed.
1-2
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description



Section 7.0 contains a summary of operational and organizational impacts.
Section 8.0 presents an analysis of the proposed system and discusses its advantages and
disadvantages. This section also relates information regarding alternatives considered.
Section 9.0 provides a list of the terms and acronyms used in this document.
1-3
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
2. REFERENCED DOCUMENTS
Documents referenced in this ALMIS Operational Concept Description are as follows:





ALMIS Business Area Analysis Strategic Analysis Report, version 2.0,
dated May 13, 1997;
IEEE Standard 1074-1991 - Standard for Developing Software Life Cycle Processes,
dated 1991;
MIL-STD-498, Software Development and Documentation,
dated December 5, 1994;
COMDTINST M13020.1D, Aeronautical Engineering Maintenance Manual,
dated 10 March 1995; and
ALMIS Business Process/Information Systems Comparative Analysis Report,
version 1.0, dated October 14, 1997.
2-1
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
3. CURRENT SYSTEM OR SITUATION
3.1 Background
The USCG Office of Aeronautical Engineering is in the process of merging its two logistics
information systems, ACMS and the AMMIS, into one Aviation Logistics Management
Information System (ALMIS). The first step in the merge was recently completed with the
physical relocation of ACMS from a contract-leased facility to the Aircraft Repair and Supply
Center (AR&SC), a Government-owned facility. Both ACMS and AMMIS operate on the same
hardware architecture and both are compatible with Portable Operating System Interface for
Computer Environments (POSIX) and Government Open Systems Interconnection Profile
(GOSIP) standards.
3.2 Objectives
ALMIS concept objectives as described in the ALMIS Strategic Analysis Report, version 2.0,
dated May 13, 1997 are to develop:

An ALMIS logistics decision support process and Executive Information System (EIS)
that provides the top-level means for relating Coast Guard aviation logistics resource
investments (i.e., personnel, equipment, facilities, and dollars) to availability and mean
logistics delay time (MLDT). The EIS shall also provide the following summary data in
conjunction with other CG logistic systems at the enterprise level:
 Availability (A0) - a function of the logistic systems reliability and is expressed as
Mean Time Between Failure (MTBF);
 Maintainability - a function of both the individual aircraft type design parameters and
the logistics environment provided by the USCG and is expressed as mean time to
repair (MTTR);
 Supportability - a function of the USCG’s logistic environment provided for each
aircraft type and is expressed as Mean Logistic Delay Time (MLDT);
 MLDT - represents the administrative delays and delays from the logistic elements
such as: Supply Support, Maintenance Planning, Technical Data, and Training; and
 Reliability - a function of the individual aircraft type and its components design
parameters.

An ALMIS Decision Support System (DSS) that automates the decision support process
and provides the bottom-line performance indicators (e.g., MLDT and cost) that reflect
how well logistics resources are allocated;
An ALMIS EIS that provides additional indicators to help interpret DSS retrospective
analysis and to constrain DSS “what if” analyses to credible and defensible alternatives;

3-1
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description


An ALMIS that provides additional indicators to help interpret and constrain DSS
analyses while meeting day-to-day logistics and maintenance management information to
line logistics officers (e.g., Air Station Engineering Officer and Depot Inventory
Manager); and
An Aircraft Troubleshooting Expert System (ATES) that will aid Air Station shop
personnel in quickly determining possible solutions to unscheduled maintenance
problems.
A final objective of ALMIS is to reduce Source of Data Entry. Elements of ALMIS that will
assist in this effort include:




Reduction in data input functions and redundant data storage requirements.
Automation of Manual Logistics Calculations. Calculations required to perform logistics
planning, including scheduled and unscheduled maintenance, deployment, reliability,
maintainability, availability, and Programmed Depot Maintenance (PDM) planning shall
be automated and supported by the ALMIS DSS and EIS.
Data Entry Integrity. ALMIS shall have the capability to detect data range and logical
entry errors.
Common Data Entry and GUI Standards. ALMIS shall have common standards defined
across the system for the following:
 Commands to direct execution of a procedure,
 Function Key representation of commands,
 Display property controls,
 Edit patterns,
 Screen Formats,
 Field prompts, and
 Common Exit State Definitions.
3.3 Scope
The ACMS module of ALMIS performs scheduling and reporting tasks in support of the
maintenance activities for the Coast Guard’s fixed and rotary wing aircraft, Mandatory Special
Requirements (MSRs) items, and selected Special Requirements (SRs) items. ACMS also
manages aircraft configuration data to provide tracking and maintenance history for all items
designated as Serial Number Tracked (SNT) components or assemblies. The tracking of
maintenance, repairs, calibration, and transportation times of avionics equipment and aircraft
components is also performed. Operational, managerial, and system reports are produced on
demand, and on an automated basis. Trend and statistical analysis of ACMS data supports the
Coast Guard's Reliability Centered Maintenance (RCM) program. ACMS users, through a User
Friendly Interface (UFI), are able to make an interactive query of the database and retrieve
historical data about a component's status and configuration information.
The AMMIS module of ALMIS supports the Flight Operations, Financial, Supply and
Procurement business areas. This module includes the following activities:
3-2
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description




Flight Operations:
 Operational Facility (OPFAC) Aircraft, including Receipt and Transfer Management,
 OPFAC Personnel Management,
 CG Aircraft Flight Record (4377) Data, and
 Aircrew Training & Qualifications Management;
Fiscal Accounting:
 Ledger Accounts Management,
 Personnel Services Management,
 Industrial Services Management, and
 Data Tables Maintenance;
Supply:
 Scheduled and Unscheduled Inventory,
 Perform Inventory,
 Inventory Management, and
 Parts Shipment and Tracking, including 265 parts; and
Procurement:
 Maintenance Requirement Package Management,
 Government Furnished Property Accounting,
 Purchase Request Administration, and
 Purchase Obligation Management.
3.4 Operational Policies and Constraints
The operational assumptions and constraints of ACMS and AMMIS are contained in applicable
instructions, including:








COMDTINST M3710.1C, Coast Guard Air Operations Manual, dated MAY 26 1993,
COMDTINST 4121.4, Coast Guard Uniform Supply Operations Manual, 25 March 1993
COMDTINST 4400.19, Supply Policy & Procedures Manual, dated 20 November 1992
COMDTINST 5230.42A, Coast Guard Data Element Naming Standards, dated May 17
1996
COMDTINST 5500.13A, Automated Information Systems (AIS) Security Manual, dated
July 24, 1987
COMDTINST 7300.6, Accounting Manual, dated February 4, 1987
COMDTINST M13020.1D, Aeronautical Engineering Maintenance Manual, dated 10
March 1995; and
Federal Acquisition Regulations (FAR).
A contingency plan is available at the AR&SC and USCG Air Stations in the event of a major
system degradation.
3.5 Description of Current System or Situation
3-3
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
3.5.1 Required States and Modes
ACMS and AMMIS have no required states or modes.
3.5.1.1 Data Processing Support Functions
Data processing support function requirements are:




ACMS and AMMIS support five business areas (Maintenance Management, Supply
Management, Financial Management, and Procurement Management, and Flight
Operations);
ACMS and AMMIS obtain, provide, and disseminate logistics information to users across
the aviation logistics community;
Human-Machine Interface is text-based; and
Neither ACMS nor AMMIS have the ability to inform on-line users of system problems
and provide users with the capability to communicate directly with system operators.
3.5.1.2 Backup and Recovery Operations
Backup and recovery operational requirements include:


Data Archiving - The ACMS and AMMIS Contingency Plans contain backup and disaster
recovery plans and are based on the USCG Management Information Systems Division
(MISD) Disaster and Recovery Plan; and
Survivability - Requirements such as backups or redundant databases maintained for
optimum recovery potential, and off-site storage facilities are accomplished in accordance
with the USCG MISD Disaster and Recovery Plan and applicable MISD Standard
Operating Procedures (SOPs).
3-4
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
3.5.1.3 Periods of Operation and Availability
Periods of operation and availability requirements are:



The processing and communications facilities that support ACMS and AMMIS operate
continuously;
ACMS and AMMIS are required to maintain an availability of 95 percent; and
ACMS and AMMIS reside in normal office spaces.
 No special environmental considerations are required other than those that may be
reasonably expected for a normal office working environment.
 Main processing equipment reside in a computer center.
3.5.2 System Components
3.5.2.1 Hardware
ACMS and AMMIS both operate on a DEC 2100/Sable host computer located at the AR&SC
Management Information Systems Division. Each host is interfaced through a DEC 5000 office
workstation front end, which provides user access by Coast Guard Standard Workstations
(CGSWs) over the Coast Guard Data Network (CGDN). The development server is a separate
DEC 3000 with 3 DEC25 workstations as the front end. Maintenance and support are provided
by government employees and contractor personnel.
3.5.2.2 Software
The DEC 2100/Sable host computer is running an OSF/I, Version 1 operating system and
applications software is written in INGRES Version 6.4. Maintenance and support are provided
by government employees and contractor personnel.
USCG Aviation upgrade plans include AMMIS Flight Operations module migration to the
OpenIngres 2.0 Relational Database Management System (RDBMS). This software upgrade will
include database redesign to enable needed functionality. Data will be mapped to the new
database, cleansed, and validated prior to data migration.
3.5.3 Interfaces
Internal and external interfaces of the current systems are included in the Entity Relationship
Diagram of the ALMIS Strategic Analysis Report, Attachment 1, and include any current paper
processes.
3.5.4 System Functional Requirements
Functional decomposition of the ACMS/AMMIS “As-Is” system is included in the BPwin
diagrams provided as Appendix B. The decomposition diagrams contains both automated and
hand processes.
3-5
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
3.5.5 Performance Characteristics
AlphaServer 2100 4/233
CPU Features
Number of Processors
CPU/ Clock Speed
Up to 4
21064/233 MHz
Cache Size
(on chip/on board)
16 KB I-cache, 16 KB D-cache/ 1 MB per
processor
Performance
TPS
LINPACK
Up to 675 TPS
Up to 407.12
I/O Features
Maximum Memory
Maximum Disk (in cabinet/total)
Maximum I/O Bandwidth
I/O Support
2 GB (1 GB for 4-CPU model)
2100: 68.8/ 610 GB
2100 CAB: 172 GB / 650 GB
132 MB/s.
3 PCI slots, 8 EISA slots, Fast SCSI-2, FW SCSI,
FWD SCSI-2, RAID, Ethernet, DSSI, FDDI,
Token Ring, Prestoserve, Synchronous
Communications
High Availability Features
OpenVMS Clusters
UNIX Clusters
High Availability Features
Supported
Operating Systems
Ethernet, DSSI, FDDI, SCSI
DECsafe ASE
Auto reboot, thermal management, redundant
power system, remote system management, RAID,
disk hot swap, dual SCSI backplane4, memory
failover, ECC memory, ECC cache, SMP CPU
failover, error logging, optional UPS. Also with
CAB: multiple systems, multiple power sources,
dual-ported storage, optional integrated UPS
Digital UNIX, OpenVMS, Windows NT
Packaging
Enclosure
Pedestal, Cabinet, Rack mount
3.5.6 Safety Requirements
Safety requirements are those requirements which, if violated, could result in unintended death,
injury, loss of property, or environmental harm. No safety-critical requirements have been
identified for ACMS or AMMIS.
3.5.7 Security Requirements
The overall system structure contains security and system administration functions. If these
subsystems fail, a breach of system security may occur.
3-6
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
ACMS and AMMIS have permissions set for read, write, and executable access on files and
directories. The systems also allow for password permission in order to gain access to systems
files and directory structures. These permissions are set by the system administrator to eliminate
unauthorized access to the system.
3.5.8 Privacy Requirements
The AMMIS Financial Management module contains information that is covered by the Privacy
Act. The operating system and database privileges restrict data access to authorized users.
3.6 Users or Involved Personnel
ACMS and AMMIS users (military, government civilians, and support contractors) at 24 Air
Stations and the Aircraft Repair and Supply center document logistics information and manage
five business areas supporting Air Station and Depot Maintenance; Flight Operations; Air Station
and Depot Supply; Fiscal Accounting; and Procurement. Air Station personnel typically
document and manage logistics information related to organizational maintenance, supply, and
operations. The AR&SC personnel typically document and manage logistics information on an
enterprise level, including depot maintenance and supply, procurement actions, and financial
transactions.
3.7 Support Concept
3.7.1 Hardware
Support for ACMS and AMMIS hardware is addressed in paragraph 3.5.2.1.
3.7.2 Software
Support for ACMS and AMMIS software is addressed in paragraph 3.5.2.2.
3.7.3 Interfaces
ACMS and AMMIS interfaces are addressed in paragraph 3.5.3.
3.7.4 Operation and Support
System operation, maintenance and support; quality assurance; and configuration management
are performed by Government employees and contractor personnel. Change management,
trouble reports, and updates are tracked and recorded.
3.7.5 Training
ACMS and AMMIS both feature a structured training program for users, based on level of access
and functional need. Database Administrators receive a combination of formal classroom
training and on-the-job training.
3-7
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
4. JUSTIFICATION FOR AND NATURE OF CHANGES
4.1 Justification for Change
The following describes the deficiencies inherent in the ACMS and AMMIS legacy database
systems:






ACMS and AMMIS operate under the Ingres 6.4 version 05 RDBMS, an older RDBMS
that does not feature new development tools. Therefore, development of new
applications and functionality take longer and are more costly Additionally, AMMIS is a
patchwork of different mini-programs that enable different functions. This reduces the
efficiency of database operation, induces data errors, and requires significantly more
maintenance than a well-designed database operating inside a modern RDBMS.
Many functions originally planned for the two databases, especially AMMIS, were never
activated. This loss of functionality significantly reduces the effectiveness of the logistics
processes and causes many of them to be performed individually by hand or by desktop
computers.
ACMS and AMMIS require many of the same data elements, but they are not integrated,
nor do they share interfaces for data transfer between the two databases. This failure to
share data results in the same data having to be entered two or more times.
ACMS and AMMIS are both text-based systems. Text-based screens do not feature the
inherent flexibility of GUI systems. Data entry and retrieval take more time than data
entry accomplished through a combination of drop-down menus and text.
Neither ACMS nor AMMIS have external interfaces to other USCG or Department of the
Treasury database systems. Data transfer between these systems must be accomplished
by downloading data to disk and then transmitting it via modem or sending it via
commercial carrier. This process requires significant manual intervention. Integration
with the Large Unit Financial System (LUFS) was documented in the Comparative
Analysis Report as a new ALMIS requirement.
ACMS and AMMIS provide only limited query capability for their databases.
Establishment of a DSS and an EIS is documented in the Comparative Analysis Report as
a very high priority for ALMIS.
4.2 Changes
The following summarizes new/modified capabilities/functions, processes, interfaces, and other
changes needed to correct the deficiencies identified in subsection 4.1:



Migration of ACMS and AMMIS functionality using modern programming practices and
tools,
Increasing system functionality by enabling previously designed functionality and to
fulfill new system requirements,
Development of new applications to replace activities performed individually by hand or
by desktop computers,
4-1
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description




Creation of external links between the databases to enable data sharing and facilitate
Source of Data Entry
Creation of external links to other databases to facilitate data transfer,
Elimination of text-based screens and incorporation of GUI and WWW technologies, and
Creation of a DSS/EIS database.
4.3 Priorities Among the Changes
As part of the ALMIS Strategic Analysis task, the OAO ALMIS team visited USCG
Headquarters, five USCG Air Stations and the Aircraft Repair and Supply Center (AR&SC) to
conduct working sessions and interviews with key personnel. One product of these working
sessions and interviews was the ALMIS “To-Be” Logical Model from which a list of 150 ALMIS
Objectives, or USCG Aviation activities, were derived. Unless pertaining to a DSS or EIS, these
objectives normally pertain to only one business area, i.e., Maintenance, Procurement, etc.
Appendix C provides a functional correlation of system capability with these ALMIS
Objectives.
A separate product of the Strategic Analysis was the documentation of ALMIS requirements not
currently satisfied by the ACMS and AMMIS legacy systems. The “new” requirements the OAO
analysts recorded include intended, but non-functional, ACMS and AMMIS processes; processes
performed by desktop computers; processes performed on paper and Measures of Effectiveness
needed for the DSS/EIS. Many of these requirements cross the boundaries of the various
Aviation business area.
Following the conclusion of the Strategic Analysis task, USCG representatives prioritized these
“new” requirements as follows:



“A” = Must have (Essential),
“B” = Could really use (Desirable), and
“C” = Nice to have (Optional).
In performance of the Business Process/Information Systems Comparative Analysis task, OAO
analysts determined which of the ALMIS Objectives would be satisfied by each of the eight
alternative concepts. The details of each of these eight analyses are contained in Attachments 1
through 8 of the Comparative Analysis Report.
At the request of USCG representatives, OAO also analyzed which of the “new” requirements
would be satisfied by each of the eight alternatives. To accomplish this analysis, OAO analysts
compared the Objectives satisfied by each of the ALMIS alternatives to the “new” requirements.
The results of this analysis are in Appendix D.
4-2
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
4.4 Changes Considered But Not Included
The ALMIS system design was originally one of eight alternatives compared against each other
with respect to performance of weighted selection criteria. The ALMIS system selected does not
satisfy 100% of the ALMIS objectives derived from the ALMIS “To-Be” process model, nor
does it satisfy 100% of the new ALMIS requirements developed during the ALMIS Business
Area Analysis.
In order for this design to meet 100% of the ALMIS “To-Be” objectives, the remaining
functionality represented by these objectives would need to be added. A new logical design of
the alternative would be required that traced to all “To-Be” objectives. Addition of this
functionality could be accomplished via pre-planned product improvements. The estimated cost
of these modifications was beyond the scope of the analysis.
The following objectives are not supported by this system:

Flight Operations
 Query Transfer Section

Maintenance
 Perform Contracted Maintenance (Depot)
 Evaluate Stock Levels (Depot)
 Verify Need (Depot)
 Plan Deployment (Air Station)
 Aircraft Troubleshooting Expert System (ATES)

Procurement
 Manage Annual Procurement Plan and Submit to HQ
 Solicit for Contract
 Establish Contract
 Administer Contract
 Perform Start-Up Activities
 Perform Contract Operations
 Close Out Contract
 Manage Procurement Reporting and Analysis
 Perform Pre-Award Procurement Reporting and Analysis
 Perform Post-Award Procurement Reporting and Analysis

Headquarters Module
 Manage HQ Aviation
 CGHQ Decision Support System
 PDM Process Assessment
 Stakeholder Satisfaction
 Resource Utilization
4-3
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description





Quality Yield
CGHQ Executive Information System
CGHQ Presentation Support
CGHQ Query Support
CGHQ Enterprise Functional Support
An Aircraft Troubleshooting Expert System (ATES) that will aid Air Station shop personnel in
quickly determining possible solutions to unscheduled maintenance problems.
4.5 Assumptions and Constraints
Required “new requirements” needed to meet objectives not satisfied by the “As-Is” system
functions are listed in Appendix D. This particular ALMIS system satisfied 83% of the
objectives derived from the ALMIS Logical Model. The following assumptions and constraints
from the ALMIS Comparative Analysis were used as a basis for the elimination of alternatives
from a top-level perspective




An alternative must meet or exceed the thresholds of all selection criteria, or it is not a
viable alternative, and
An alternative must provide process improvement in day-to-day tasks associated with
USCG Aviation Logistics.
External interfaces were selected based on the logical model developed for ALMIS, and
At the logical level, counts for entities and relationships are approximate due to the
different possible physical implementations of the model.
4-4
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
5. CONCEPT FOR A NEW OR MODIFIED SYSTEM
5.1 Background, Objectives, and Scope
5.1.1 Background
The Coast Guard completed a BAA of its Aviation Logistics Management Information System
(ALMIS). ALMIS is intended to integrate the functionality of both the Aircraft Computerized
Maintenance System (ACMS) and the Aviation Maintenance Management Information System
(AMMIS). In addition, non-automated processes identified and prioritized by USCG
representatives will be integrated into ALMIS.
5.1.2 Objectives
The ultimate objective of the ALMIS project effort is to develop and deploy an integrated
aviation logistics management system that will be capable of supporting the following business
processes:






Aircraft Flight Operations,
Aircraft Maintenance and Configuration,
Fiscal Accounting,
Procurement Management,
Aviation Supply, and
Aviation Headquarters.
5.1.3 Scope
This system incorporates the functionality represented by 84% the high-priority “new”
requirements listed in Appendix D into ALMIS. This is a significant increase in functionality
over the baseline (ACMS and AMMIS legacy systems) system. The baseline (“As-Is”) process
model (including paper processes) is provided in Appendix B.
It also features the use of the INGRES DBMS, the development of an Intranet topology, and the
installation of servers at each Air Station with Air Station Flight Operations, Aviation Supply,
and Aviation Maintenance Modules, and the database installed.
This feature will increase availability and reliability, and ensure uninterrupted service at Air
Stations when the AR&SC server is down or when telecommunications are disrupted.
Intranet topology would include a Windows NT 4.0 Server, a WWW browser such as Netscape
Navigator, and a network installable Telecommunications Control Protocol over Internet
Protocol (TCP/IP) stack that has security, switching, and router discovery and software and
hardware that supports interactive discussion software.
5-1
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
The proposed system also features:



The use of FLS Procurement and Financial Management Module processes and database
logical designs,
The ALMIS external interfaces, and
The FLS Maintenance and Supply Management Modules, Operational Policies and
Constraints
5.1.4 Assumptions
Assumptions pertaining to ALMIS are as follows:





ALMIS shall satisfy the requirements of COMDTINST M13020.1D, Aeronautical
Engineering Maintenance Manual, dated 10 March 1995;
A contingency plan is available at the AR&SC and USCG Air Stations in the event of a
major system degradation;
The source of data entry (clerical burden on supply and maintenance personnel) is
reduced by decreasing the need for redundant data entry;
Training materials will be available to train all users; and
Documentation will be available to facilitate maintenance after installation of ALMIS.
5.1.5 Constraints
USCG representatives designated nine ALMIS system performance criteria that OAO analyzed
with respect to redesigning the existing ACMS and AMMIS Flight Operations Modules, and
integrating them with the Fleet Logistics System (FLS) Supply, Procurement, and Finance
Business Modules. A description of each criterion is provided in the following subparagraphs.
5.1.5.1 Operational Availability
Operational Availability (Ao) is the probability that, when used under the stated conditions, a
system will operate satisfactorily at any time. Ao includes standby time and administrative and
logistic delay time. The formula applied is as follows:
Ao =
Uptime
Uptime + Downtime
Uptime is the time during which the host computer central processing unit (CPU) is operational
and at least one terminal can communicate with the host computer via a LAN. Downtime is the
time during which the system is down for repair of critical hardware failures and/or for
restorations from mission critical faults, including off-board logistics delays.
5-2
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
5.1.5.2 Software Product Complexity
Function Point Analysis was used to compute ALMIS Software Product Complexity. Function
points were applied to the Software Life Cycle Cost estimate using the COCOMO detailed cost
model in COSTAR.
Unadjusted Function Point descriptors are as follows:





Internal Logical Files,
External Interface Files,
External Inputs,
External Outputs, and
External Inquiries.
Factors which affect Software Product Complexity include:






ACMS and AMMIS - Flight Operations will be migrated to OpenIngres,
AMMIS will use the Fleet Logistics System (FLS) Supply, Procurement, and Finance
modules,
FLS Modules will be implemented as designed, no logical table counts from FLS
modules,
Flight Operations is not included in redesign; no Flight Ops logical tables are included,
Include all logical tables from “As-Is” ACMS model, and
No interfaces are defined between Flight Ops and FLS modules.
5.1.5.3 Source of Data Entry
Source of data entry impact is the change in the number of relative hours required to perform
data entry as compared to the existing MIS. This selection criteria cannot be estimated until the
project reaches physical design, and cannot be calculated until the product is implemented.
However, integration of databases and implementation of modern technology, such as a GUI or
WWW presentation technology, can reduce Source of Data Entry.
5.1.5.4 Data Transfer Integrity
Data Transfer Integrity (DTI) is ascertained by applying the following formula:
DTI =
Total number of correct system actions performed
Total number of system actions performed
The impact of data integrity design has been included calculation of cost and schedule in this
alternative analysis. The data cleansing and data migration are included in the final cost
estimate.
5-3
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
5.1.5.5 Changes to User Interface
The user interface consists of the dialogs between the system and its users, and the individual
screen displays that comprise the dialog. Changes to User Interface, therefore, is a measure of
the total number of changes in the way data is presented to, and manipulated by, the user. This is
an indictor of the difficulty the user will face in being retrained to use the new system.
ACMS and AMMIS Flight Operations will be migrated to OpenIngres 2.0 while the three FLS
modules will employ the Oracle 7 RDBMS. All current text-based screens will be replaced by
GUI and WWW presentation technologies.
5.1.5.6 Percentage of ALMIS Objectives Met
Percent of Objectives Met is the percentage of high priority ALMIS requirements met by the
alternative design. For this analysis, the ALMIS objectives were derived from the Logical
“To-Be” model. The functionality of the alternative was then compared to these objectives to
obtain the value for this selection criterion.
5.1.5.7 Life Cycle Cost
Life cycle cost is defined as the total cost of requirements management, development, test,
implementation, maintenance, and retirement of ALMIS over a 10-year period. Development
and yearly maintenance costs for this alternative were derived using the COSTAR and Cost
Xpert CASE tools. Year 2000 (Y2K) database restructuring will be accomplished as part of the
detailed design and is accounted for in the Development Cost estimate.
5.1.5.8 Completion Schedule
The time in months from project initiation to project completion, including physical design,
product development, software testing, initial installation and test, and user training. The Cost
Xpert CASE tool calculates completion schedule in terms of Staff Months.
5.1.5.9 Program Risk
ALMIS Program Risk is defined by the total potential cost which could be attributed to a
combination of Cost Overrun and User Requirements Creep.
5.2 Description of the Modified System
5.2.1 ALMIS System Description
This ALMIS solution will involve redesigning the existing ACMS database and AMMIS Flight
Operations module in OpenIngres 2.0; redesigning the Supply, Procurement and Financial
Management modules from the Fleet Logistics System (FLS), written in the Oracle 7 DBMS, to
fit USCG Aviation business rules; enabling needed functionality in the Flight Operations
module, creating interfaces between ACMS, the Flight Operations module, and the FLS modules;
and cleansing historical data prior to data migration to the new database structures. This system
5-4
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
will feature a GUI and WWW technologies for data presentation and Internet technology for
communications and data transfer. A DSS will provide the ability to compare current
performance with established USCG standards and metrics. An EIS will provide access to
historical data and enable trend analysis for decision makers.
This system includes all the functionality of ACMS and AMMIS in the Maintenance and Flight
Operations modules, as well as adding some needed functions to the Flight Operations module.
FLS modules for Procurement, Finance, and Supply will be used which means that the
functionality of these modules will be identical to the functionality of FLS. As designed, the FLS
modules provide all the functionality of the AMMIS modules of the same name. This system
will not include the Coast Guard Headquarters Module.
Cost Xpert, a Constructive Cost Model (COCOMO) tool, was used to analyze the system for
cost, schedule and risk. The detailed analysis may be found in Appendix E. Reports provided
include:







Input Data Report,
Correlation Report,
Tasks Report,
Risk Report,
Labor Report,
Maintenance Report, and
Deliverables Report.
5.2.2 Required States and Modes
ALMIS is required to operate in two modes—peacetime and national emergency. The following
subsections identify and describe these two modes of operation for ALMIS.
5.2.2.1 Data Processing Support Functions
5.2.2.1.1 Peacetime Mode
Peacetime data processing support function requirements are:





ALMIS shall provide support in the functional areas (ALMIS Maintenance Management,
Supply Management, Financial Management, and Procurement Management, and Flight
Operations);
ALMIS shall obtain, provide, and disseminate logistics information to users across the
aviation logistics community;
ALMIS shall incorporate reasonable controls on data and system access;
Human-Machine Interface shall be GUI to the maximum extent possible;
ALMIS shall have the ability to inform on-line users of system problems and provide
users with the capability to communicate directly with system operators.
5-5
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description


ALMIS shall be sized and configured to meet the response time requirements specified in
the ALMIS Strategic Analysis Report (SAR); and
The Response Time is defined as the elapsed time from the last keystroke of user input
until the first character of data transaction is displayed at the user’s terminal. Response
Time requirements shall have the following thresholds and objectives:
 Between five (5) and ten (10) seconds at least eighty-five percent (85%) of the peak
access time,
 Between ten (10) and thirty (30) seconds no more than ten percent (10%) of the peak
access time,
 Between thirty (30) and sixty (60) seconds no more than four percent (4%) of the peak
access time,
 Greater than sixty (60) seconds no more than one percent (1%) of the peak access
time,
 Mean Response Time for Data Inquiry/Retrieval (MRTdir) (11 Seconds), and
 Mean Response Time for Data Update and Modification (MRTdurm) (16 Seconds)
5.2.2.1.2 National Emergency Mode
A state of national emergency requires an increased state of readiness and awareness on the part
of ALMIS users. In the national emergency mode, ALMIS shall meet all peacetime data
processing support operational requirements, and:



Handle increased user demands caused by the national emergency;
Support the logistics community during a state of national emergency by providing more
frequent updates of platform-level information; and
Response Times for this mode shall be no less than that previously described in paragraph
5.2.2.1.1.
5.2.2.2 Backup and Recovery Operations
Peacetime and national emergency backup and recovery operational requirements are:


Data Archiving - The ALMIS Contingency Plan shall contain backup and disaster
recovery plans and be based on the USCG Management Information Systems Division
(MISD) Disaster and Recovery Plan; and
Survivability - Requirements such as backups or redundant databases maintained for
optimum recovery potential, and off-site storage facilities shall be accomplished in
accordance with the USCG MISD Disaster and Recovery Plan and applicable MISD
Standard Operating Procedures (SOPs).
5-6
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
5.2.2.3 Periods of Operation and Availability
Peacetime and national emergency periods of operation and availability requirements are:



Maintain an availability of 95 percent;
The processing and communications facilities that support ALMIS shall operate
continuously; and
ALMIS is expected to reside in normal office spaces. No special environmental
considerations are required other than those that may be reasonably expected for a normal
office working environment. Main processing equipment is expected to reside in a
computer center.
Furthermore, ALMIS development shall include exploration of the feasibility to adapt the
database to support day-to-day shipboard and extended operational deployment activities in the
flight operations, maintenance and supply business areas.
5.2.3 System Functional Requirements
5.2.3.1 System External Interface Requirements
External software interface information, on a logical level, is provided in the Entity Relationship
diagram (Appendix F). Specific hardware and software external interface information will be
described in the ALMIS Interface Requirements Specification (IRS).
5.2.3.2 System Internal Interface Requirements
ALMIS internal interface requirements are defined as entities shared across business areas and
are represented in the Entity Relationship Diagram (ERD) (see Appendix F).
Detailed system internal interface requirements shall be provided in a Software Requirements
Specification (SRS) and will be further allocated in a Software Design Description (SDD).
5.2.3.3 System Internal Data Requirements
ALMIS system internal data requirements are represented by the ALMIS logical data model:
entities, attributes, and relationships, and their definitions. Data requirements support all
automatable functions which are contained within the Functional Baseline. A Create Retrieve
Update and Delete (CRUD) will provide a mapping of the data input or output of a function(s).
An Input, Retrieve, Update, Null, (IRUN) will provide the actions that can be performed on an
attribute. A logical representation of the ALMIS data requirements will be evaluated using
Entity Relationship Diagrams, CRUD and IRUN matrices which will be provided as part of the
ALMIS Functional Baseline (FBL) System/Subsystem Specification (SSS).
Detailed System Internal Data Requirements shall be further allocated and provided in an ALMIS
Database Design Description (DBDD). Those reports shall include, but not be limited to:

Database Objects,
5-7
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description



Table Definitions,
Constraint Definition, and
Tables and their Indexes.
5.2.4 ALMIS Performance Threshold Values
Table 5-1 provides ALMIS performance threshold values.
Table 5-1. ALMIS Performance Threshold Values
PERFORMANCE PARAMETERS
ALMIS THRESHOLD
Mean Response Time for Data Inquiry
11 Seconds
Mean Response Time for Data Retrieval
11 Seconds
Mean Response Time for Data Update and Modification
16 Seconds
Data Transfer Integrity
0.99
Mean Time Between Mission Critical Faults for Software
660 Hours
Mean Time Between Mission Critical Failures for Hardware
1300 Hours
Maintainability (Mmax)
48 Hours
Mean Reboot Time
10 Minutes
Availability (Ao)
0.95
Database Size
13,000 MB
5-8
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
5.2.5 ALMIS Server Performance Values
Table 5-2 delineates performance values for the ALMIS server.
Table 5-2. Digital AlphaServer 4100 5/400 System Performance Values
DIGITAL ALPHASERVER 4100 5/400 SYSTEM
Number of processors
CPU/clock speed
Cache size (on-chip/on-board)
In-cabinet CPU upgrade
Up to 4
21164/400 MHz
8 KB I-cache, 8 KB D-cache, 96 KB secondary/ 4 MB per processor
Yes
PERFORMANCE
SPECint95®
12.1
SPECfp95®
17.2
SPECfp95® SMP
33.4
SPECint_rate95®
422
SPECfp_rate95®
439
LINPACK 1000 x 1000
1,841
SPECweb96®
-MAXIMUM CONFIGURATIONS
Maximum memory
8 GB
Maximum disk capacity (inPedestal: 190 GB/over 15 TB
cabinet/total)
Cabinet: 510 GB/over 15 TB
Maximum I/O bandwidth
500 MB/s
I/O support (max. config.)
8 64-bit PCI slots (including 3 shared PCI/EISA slots)
2 64-bit PCI channels
Standard features
1.44 MB diskette drive, CD-ROM drive, 10/100 Mbit Ethernet controller, FWSE
SCSI-2 controller, integral FNSE SCSI-2 bus for removable media (CD-ROM and
tape), S3 TRIO graphics adapter, 2 serial ports, 1 parallel port, keyboard and
mouse, integral remote system console, operating system license and customer
documentation, Internet software
RELIABILITY/HIGH-AVAILABILITY FEATURES
OpenVMS Clusters
Ethernet, DSSI, FDDI, SCSI, CI
UNIX Clusters (DIGITAL
TruCluster Solutions, Parallel Software Environment (with PCI to Memory
UNIX)
Channel Interconnect)
DIGITAL Clusters for
Supported
Windows NT
High-availability features
DIGITAL ServerWORKS systems management software, auto reboot, thermal
management, optional redundant power system, remote system management,
RAID, disk hot swap, memory failover, ECC memory, ECC cache, ECC system
bus, SMP CPU failover, error logging, UPS Power Management Software,
optional uninterruptible power supply (UPS). Also with a CAB: multiple systems,
multiple power sources, dual-ported storage
Storage
StorageWorks
SOFTWARE FEATURES
Operating systems
DIGITAL UNIX, OpenVMS, Windows NT
Options
Networking
Ethernet, Fast Ethernet, FDDI, Token Ring, synchronous comms., ATM3
Storage
Fast SCSI-2, FW SCSI-2, FWD SCSI-2, RAID, CI, DSSI(OpenVMS only),
Prestoserve
5-9
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
DIGITAL ALPHASERVER 4100 5/400 SYSTEM
Temperature
Relative humidity
Power Supply
Enclosure characteristics
Height
Width
Depth
Weight
Warranty
OPERATING ENVIRONMENT
10oC to 35oC (50oF to 95oF)
10oC to 35oC (50oF to 95oF)
20% to 90% (non-condensing)
20% to 90% (non-condensing)
450W
450W
Pedestal
Cabinet
75 cm (29.5 in.)
170.2 cm (67.0 in.)
49 cm (19.3 in.)
60.0 cm (23.6 in.)
90 cm (35.4 in.)
97 cm (38.2 in.)
113.6 kg (250 lbs.)
350.9 kg (772 lbs.)
Hardware: three-year, on-site, with 5x9, 24-hour response time for system drawer
and contents
Notes:
1. Using two 5/466 MHz CPUs, 4 GB, SYBASE v11.1 and DIGITAL UNIX v4.1D4.
2. Using four 5/466 MHz CPUs 5 GB, SYBASE v11.03 and DIGITAL UNIX v4.0D.
3. UNIX 4.0A or greater.
5.2.6 Adaptation Requirements
Current site-dependent data shall be converted and merged into ALMIS during the
ACMS/AMMIS data migration process. All data shall be stored on the master database and will
be updated periodically. Procedures for accomplishing these tasks shall be developed and
documented in an ALMIS Data Conversion Plan.
5.2.7 Safety Requirements
Safety requirements are those requirements which, if violated, could result in unintended death,
injury, loss of property, or environmental harm. No safety-critical requirements have been
identified for ALMIS.
5.2.8 Security and Privacy Requirements
5.2.8.1 Security Requirements
The overall system structure Computer Software Configuration Items (CSCIs) shall contain
security and system administration functions. If these subsystems fail, a breach of system
security may occur.
Three different classes of permission will be developed for system access and security. They are:
1. The owner,
2. The group, and
3. “Others.”
Each of these classes shall have permissions set for read, write, and executable access on files
and directories. The system shall also allow for password permission in order to gain access to
systems files and directory structures. These permissions shall be set by the system administrator
to eliminate unauthorized access to the system.
5-10
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
To preclude unauthorized access to data on the system, the privileges shall be set from within the
RDBMS. Application and database access shall be granted through roles in the RDBMS and be
based upon the subsystem on which a developer is working. These privileges would allow access
to data based on the user role. Each user shall have permission to access data based on their user
name. Also, privileges to applications shall be granted in the RDBMS developer tool. Users
shall be granted the following privileges:






Select,
Insert,
Update,
Delete,
Share, or
Administer/manager.
These permissions shall be set by the Database Administrator. The combination of the RDBMS
and the operating system security will minimize the possibility of a system security breach.
5.2.8.2 Privacy Requirements
The finance system CSCI will contain information that is covered by the Privacy Act. The
operating system and RDBMS privileges described in the previously shall be used to restrict data
access to authorized users. Most data in the system considered to be private will be received
through interfaces. This system shall also employ security and privacy measures to reduce the
possibility of a breach of security or privacy.
5.3 Users or Involved Personnel
Current ACMS and AMMIS users (military, government civilian, and support contractors) at 24
Air Stations and the Aircraft Repair and Supply center document logistics information and
manage five business areas supporting Air Station and Depot Maintenance; Flight Operations;
Air Station and Depot Supply; Fiscal Accounting; and Procurement. Air Station personnel
typically document logistics information related to organizational maintenance, supply, and
operations. This includes:




Maintenance actions performed,
Flight operations information,
Parts usage and issue, and
Aircraft configuration changes.
The AR&SC personnel typically document logistics information on an enterprise level,
including:




Depot maintenance and supply operations,
Aircraft Type/Model Configuration Management,
Procurement including contracting issues and procurement requests,
Enterprise-wide parts inventory issues, and
5-11
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description

Budgetary issues including fiscal commitments and obligations.
5.4 Support Concept
5.4.1 CSCI Capability Requirements
5.4.1.1 Required Behavior of the System Requirements
This section presents the requirements for the behavior of ALMIS and assumptions associated
with the measurement and testing of those requirements. These measurements shall be addressed
during the design and implementation phase, as applicable.
5.4.1.1.1 Assumptions
The measurement and testing of the behavior of the system are based on the following
assumptions:







Required behavior performance and acceptance criteria shall be based on software
performance only,
Hardware performance shall be considered as having met all behavior-related
requirements including performance,
ALMIS availability is based on 30 calendar days per month,
All enterprise servers shall reside at the AR&SC, MISD,
System availability shall be measured at the CG Aviation unit level,
No other application shall be running on the ALMIS application server, and
The lowest common interface media shall be an American Standard Code for Information
Interchange (ASCII) flat file.
5.4.1.1.2 Reliability
The inherent reliability characteristics of the system shall be acceptable. The system includes:



The DEC 4100 servers (and peripheral equipment),
CA-OpenIngres and Oracle environments, and
ALMIS applications.
5-12
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
Test procedures shall be outlined in an ALMIS Software Development Plan (SDP) and detailed
in an ALMIS Software Test Plan (STP) and an ALMIS Software Test Description (STD). This
testing shall:



Verify system compliance with those reliability characteristics,
Establish their baseline, and
Monitor the system’s adherence to them.
This will allow the identification of negative trends before they impact system performance.
5.4.1.1.3 Availability
ALMIS shall, in the event of an equipment failure, redirect the workload processing to an
operable device or component without requiring an operating system reload. Provisions for full
recovery of in-process data c also be provided.
ALMIS shall detect saturated conditions within the configuration and include provisions for
subsequent resource scheduling modifications and/or reallocation.
These requirements shall be verified and monitored in the same manner as paragraph 5.4.1.1.2.
5.4.1.1.4 Maintainability
ALMIS shall be maintainable by current resources with no increase of government personnel.
Emphasis for maintainability of ALMIS shall be on the source code, which shall not be available
to the users. Specific network and hardware components shall be assumed to be “state-of-theart” components of the ALMIS support concept and shall be assumed to be defect-free for the
purposes of software design, performance measurement, and testing.
5.4.1.2 Performance
This section covers the requirements objectives for ALMIS performance. Confidence interval
requirements shall be presented as part of software requirements and planning for verification
and validation (V&V). The two performance requirement areas are:
1. Reliability, and
2. Availability.
Response time shall be addressed as part of the reliability performance requirement and
measurement.
The ALMIS performance reliability requirement shall be less than or equal to specified threshold
and objective values.
5-13
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
The specific performance requirements metrics which shall be obtained to establish that
reliability requirements have been met during testing are as follows:








U = Utilization,
ALMIS Performance Reliability,
X = Throughput,
Q = Queue Length Distribution,
WT = Waiting Time Distribution,
SE = Mean Server’s Efficiency,
RT = Response Time distribution, and
ST = Service Time Distribution.
Reliability estimates shall be performed during each of the physical and life cycle design phases.
The following primitives may be used to quantify the basic performance attributes:






A = The number of arrivals (Functional Jobs) during a 30-day time period.
Arrivals shall be specified from 0800 to 2000 Eastern Time.
SB = The total amount of time the “server” at AR&SC will be busy.
J = The number of jobs completed during T.
VR = The number of requests (visits) per functional job for each server during a thirtyday period.
T = 30 days.
Based on the primitives above, the derived quantifiable measures shall be as follows:







 = A/T, the average arrival rate of jobs.
X = J/T, the average throughput rate.
U = SB/T, the average utilization.
AS = SB/J, the average service time.
WT = f (,U,AS,VR), the waiting time distribution (expressed as a function of arrival
rate, utilization, service time, and visit rate).
SE = A/(AS + W), the server’s efficiency for each job.
R = ki=1 (VR X S)I + ki=1 (VR X W)I.
Where:



S = service time,
W = waiting time, and
R = the total response time for each functional job over the k servers.
Each of these measures shall be used to derive the corresponding probability distribution of the
measure under the stated assumptions of the system. The distribution would then be used to
calculate the probability of achieving the required reliability level.
5-14
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
The probability of achieving the required reliability level can be calculated by developing a
performance model. The performance model shall be developed by identifying the ALMIS
critical resources and the system's supporting infrastructure connections in the form of a queuing
network model (QNM). The measures above and approximation algorithms in analytic queuing
theory and operations research techniques would be used to solve the QNM.
The reliability evaluation of response time can be evaluated as follows:


R must meet the response time criteria presented above, and
Calculate the system performance reliability as reliability = Probability (R  R0) for each
time period and associated probability objective.
Response Time may be defined as the elapsed time from the last keystroke of user input until the
first character of data transaction is displayed at the user’s terminal. The ALMIS Response Time
threshold for data inquiry and data retrieval is 11 seconds. For data update and modification, the
ALMIS Response Time threshold is 16 seconds.
5.4.1.2.1 Availability
Combined hardware and software operational availability estimates shall be performed during
each of the physical and life cycle design phases. Estimates may be calculated using the
following primitives:







 = Observed software failure rate.
 = Observed hardware failure rate (Based on actual measured performance determined
from installed hardware at AR&SC supporting ACMS/AMMIS).
ui = Observed fault correction rate with i faults in the software.
 = Observed hardware repair rate (Based on actual measured performance determined
from installed hardware at AR&SC in support of ACMS/AMMIS).
NF = Estimated number of remaining software faults.
Ps = Probability of correcting a software fault when detected ( < Ps < 1).
Ph = Probability of correctly repairing a hardware failure ( 0 < Ph < 1).
The basic Markovian Model may be used to predict combined software and hardware availability
as a function of operating time. System “up status” probabilities PNF, n (t) with n remaining
faults, given that there were NF software faults at the acceptance (t=0) of the system, may be
computed for n = 0,1,2,…N.
5-15
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
The number of software faults shall be statused as part of the following testing:






Unit,
Integration,
Computer Software Configuration Item (CSCI) Qualification,
CSCI/Hardware Configuration Item (HWCI) Integration,
System Qualification, and
Acceptance.
5.4.1.2.2 System Availability A(t) = NFn=0 PN, n (t)
System Availability which may be expressed as Operational Availability (expressed as Ao). A0 is
the probability that, when used under the stated conditions, a system shall operate satisfactorily at
any time. Ao includes standby time and administrative and logistic delay time. The formula
applied is as follows:
Ao =
Uptime
Uptime + Downtime
Uptime is the time during which the host computer central processing unit (CPU) is operational
and at least one terminal can communicate with the host computer via a Local Area Network
(LAN). Downtime is the time during which the system is down for repair of critical hardware
failures and/or for restorations from mission critical faults, including off-board logistics delays.
The ALMIS System Availability threshold is .95.
5.4.1.3 Reliability
Current CGSWIII reliability requirements shall be maintained in the ALMIS design. Many
reliability components are dependent on both hardware and software. However, due to the scope
of the ALMIS effort only software reliability shall be required to be demonstrated as part of the
V&V procedures and during component, system, and acceptance testing. The reliability
objective is directly related to system availability. Hardware shall be assumed to have met all
reliability requirement objectives. This includes the USCG wide area data network (WAN).
Provided that operational availability requirements are met, the inherent hardware reliability
characteristics of the ALMIS shall be considered to be acceptable. Measures used to establish the
acceptance criteria for software reliability shall be used to:



Verify that the inherent reliability of the hardware system is being met,
Baseline the reliability provided by the hardware, and
Monitor the system hardware reliability to ensure that it is maintained throughout the life
of the system.
5-16
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
ALMIS does not have an explicitly stated threshold for reliability. However, the following two
reliability-related thresholds apply:


Mean Time Between Mission Critical Faults (Software) = 660 hours, and
Mean Time Between Mission Critical Faults (Hardware) = 1300 hours.
5.4.1.4 Availability
ALMIS shall be able to redirect the workload processing to an operable device or component as a
result of an equipment failure, without requiring an operating system reload. Provision for full
recovery of in-process data shall also be provided.
ALMIS shall be capable of detection of saturated conditions within the configuration and
provisions for subsequent resource scheduling modifications and/or reallocations shall be
included.
These requirements shall be tested and monitored as the ALMIS application becomes available
for installation in the Software Test Environment (STE).
5.4.2 System Environment
Currently ACMS and AMMIS are hosted on separate DEC 2100 Alpha Servers. The ALMIS
system will reside on two Digital Equipment Corporation (DEC) 4100 Alpha Servers. Table 5-3
provides the specifications of the DEC 4100 Alpha Server.
5-17
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
Table 5-3. ALMIS Server Environment
DIGITAL AlphaServer 4100 System
EXTERNAL DIMENSIONS
Height
170 cm (67.0 in.)
Width
60 cm (23.6 in)
Depth
97 cm(38.2 in.)
Weight
350.9 kg (772 lb.)
CLEARANCES
Front
Operating 60 cm (23.6 in.) Service 100 cm (39.4 in.)
Rear
Operating 60 cm (23.6 in.) Service 100 cm (39.4 in.)
Sides
Operating 20 cm (7.9 in.)
Service 61 cm (24 in. in.)
ENVIRONMENTAL
Temperature (min/max)
Operating
10o - 35oC (50o - 95oF)
Non-operating
-40o - 66oC (-40o - 150.8oF)
Storage (60 days)
-40o - 66oC (-40o - 150.8oF)
Rate of Change
11o - 19.8oC/hr (20o - 36oF/hr)
Relative Humidity
Operating
20 - 90% non-condensing
Non-operating
10 - 95%
Storage (60 days)
10 - 95%
Max Heat Dissipation
4800 Watts, 16382 Btu/hr
AIR FLOW
Quantity
300 cubic ft./min
Intake
Rear
Exhaust
Front and Top
Altitude
Operating
3,050 m (10,000 ft)
Non-operating
12,200 m (40,000 ft)
Acoustics
6.7 Bels
Electrical
Voltage
200 - 240 VAC
Phase
Single
Frequency
50 - 60 Hz
Current
24 Amperes
Agency Approvals
CAN/CSA-C22.2 No. 950-M95
UL 1950, Ed. 3
5-18
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
DIGITAL AlphaServer 4100 System
EN 60 950, Ed. 2, A3
5.4.3 Computer Resource Requirements
The Coast Guard currently uses the AR&SC Frame Relay Network. As the transition of Work
Station III computers proceeds, the mostly likely Wide Area Network (WAN) replacement is the
Coast Guard Data Network (CGDN) Plus. A representative ALMIS WAN system architecture is
depicted in Figure 5-1.
HQ
Aircraft Repair and
Supply Center
Elizabeth City, N.C.
W ide
Area
Network
ALMIS
ALMIS
Disk
Master
Master
Database
Database
Server
Interfaces LUFS,
PMIS, etc.
Local
Units
Disk
Local Database
Server
Air Stations
Figure 5-1. Representative ALMIS Wide Area Network System Architecture
5.4.4 ALMIS Maintenance Requirements
The following maintenance actions shall be completed by ALMIS Database Administrators and
other ALMIS support staff personnel:

Monitor Data Integrity
5-19
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description



 Ensure data security, integrity, accuracy, currency, and timeliness.
 Collect, synchronize, and distribute data through user and system interfaces and
database/distribution architecture.
Perform Records Management
 Archive mission requirements data. Maintain the archived data and provide
availability and access to such.
 Dispose of data which offers no benefits and for which no legal requirements exist.
 Ensure the proper security of disposed data.
Perform Configuration Management
 Maintain conceptual and logical data models, external system and user mappings, and
database design as data requirements, standards, and technology change.
 Maintain database configurations.
Database Performance Monitoring
 Capture database problem reports and statistics.
 Tune database, as necessary, to optimize its performance and continually monitor data
quality and data security and take corrective actions, as required.
5.4.5 Maintenance and Life Cycle Costs
OAO analysts used the Cost Xpert Cost Model to estimate ALMIS Maintenance Costs for a 10
year system life cycle. Cost Xpert provides three life cycle cost outputs:



Maintenance
Defects, and
Support Calls.
5.4.5.1 Software Maintenance Estimates
Software maintenance includes software repairs and software updates, but does not include major
rewrites of the software that substantially change the functionality of the available software. This
is normally best treated as a separate, follow-on project. Maintenance can be categorized at a
high level into:



Corrective Maintenance - Correcting software defects (bugs);
Adaptive Maintenance - Adapting the software to handle changes in the environment,
including things like changes to the operating system, database management system, and
input files; and
Perfective Maintenance - Making improvements in the software’s functionality, usability,
reliability, performance or security.
5-20
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
Figure 5-2 shows the US average distribution of maintenance activities broken down by
category.
Distribution of Software Maintenance Effort
Emergengy program fixes
3.4
0
Routine debugging
4.0
0
Accommodate changes
5.5
0
Accommodate changes to
41.8
0
Enhancements for users
6.2
0
Improve documentation
17.4
0
Improve code efficiency
9.3
0
Other
12.4
0
0
5
10
15
20
25
30
35
40
45
Precent of Software Maintenance Effort
Figure 5-2. Maintenance Activities Broken Down by Category
Cost Xpert predicts both the maintenance effort for each year of the project and the projected
maintenance, adjusted for inflation. Appendix E includes projected maintenance costs for each
year of the cycle and the total projected maintenance cost.
5.4.5.2 Software Defect Estimates
The second output available is the estimated defects by year, along with a breakdown showing
the estimated defects by defect category. This information is useful when planning the
maintenance effort, but is even more useful when assessing system quality. If the system has
significantly more defects than predicted by the industry averages, the software process and
quality assurance activities need examination.
5.4.5.3 Support Calls
Cost Xpert predicts the number of support calls that will be received in each year following the
introduction of the software. The call volume will tend to peak during times when new versions
of the software are released.
5-21
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
5.4.6 Process and Data Models
5.4.6.1 ALMIS Integration Definition for Function Modeling (IDEF0) - Process Model
This standard describes the IDEF0 modeling language (semantics and syntax), and associated
rules and techniques, for developing structured graphical representations of a system or
enterprise. Use of this standard permits the construction of models comprising system functions
(activities, actions, processes, operations), functional relationships, and data (information or
objects) that support systems integration. This model is provided as Appendix B.
5.4.6.2 ALMIS Integration Definition for Function Model (IDEF1X) - Data Model
Included as part of the ALMIS Data Model are the following:






Phase Three (key-level) diagram (Appendix F),
Entity Definition Report (Appendix G),
Key Attribute List (Appendix H),
Attribute Definition Report (Appendix I),
Relationship Report (Appendix J), and
Entity Relationship Cross-reference (Appendix K).
5.4.7 Design and Implementation Constraints
The ALMIS design constraints specify that the system must be integrated and must support the
automated information system. The construction constraints of ALMIS must show linkages
between functions and data for all applicable functional areas such as supply management;
maintenance management; financial management; and procurement management, and flight
operations.
The ALMIS approach features completion of Flight Operations and the reengineering of ACMS
to include all system requirements as described in paragraph 5.2. The final increment of ALMIS
will be the integration of the three FLS modules via Web implementation.
Software implementation at the unit level will occur using a combination of Spiral Methodology
and RDBMS CASE tools. Standards and specifications shall be provided to the developers in a
consistent manner via the following documents, as applicable:






System/Subsystem Specification (SSS),
System Requirements Specification (SRS),
Interface Requirements Specification (IRS),
Software Design Description (SDD),
Interface Design Description (IDD), and
Database Design Description (DBDD).
5-22
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
A unit shall not be approved for integration into a function until Quality Assurance/Verification
and Validation (QA/V&V) has certified that all standards have been met or appropriate tailoring
documented.
5.4.7.1 Design or Construction Standards
ACMS shall be migrated to an OpenIngres 2.0 RDBMS environment using the appropriate
CASE tools.
The FLS Supply, Procurement, and Financial Management modules shall be developed in the
Oracle CASE and Oracle Version 7.3.2.3.0 or higher RDBMS environment. Designer/2000
Version 1.3.2 or higher shall be the CASE tool utilized and SQL Net Version 2.3 or higher shall
be used as the communication link.
Additionally, design and construction standards shall adhere to MIL-STD-498 and Information
Systems Technology Architecture (ISTA) Manual, COMDTINST M5230.45A. Naming
conventions and standards shall be adhered to as set forth in the Coast Guard’s Data
Administration Plan and Procedures Manual #CG-ELC-SOP-AFL.1 and the Department of
Defense Data Standardization Procedures Manual #DOD8320.1-M-1.
5.4.7.2 Identifying Markings
In general, all software products shall be identified by a version control number and managed
with an appropriate tracking tool. All hardware shall be identified by a serial number and an
inventory control list. The detail requirements for nameplates and serial and lot number
markings shall be addressed in an ALMIS Software Installation Plan and an ALMIS
Configuration Management Plan.
5.4.7.3 Flexibility and Expandability
The system’s design and construction shall be developed with flexibility and expandability
accounted for by the Hardware/Software (HW/SW) packages and an ALMIS Software
Development Plan.
The SDP shall be developed with close attention to the MIL-STD-498 and the ISTA Manual,
COMDTINST M5230.45A. The combination of leading technology software tools and the plans
shall support efforts to design, build, and deploy a flexible and expandable application in the face
of anticipated areas of growth or changes in technology, threat, or mission.
5.4.8 Personnel-Related Requirements
ALMIS users will consist of integrated teams of Coast Guard military and civilian personnel.
These individuals will be well-trained operators with knowledge of the business areas supported
by ALMIS. These individuals will have knowledge of one or more of the functional areas of
engineering services, configuration management, maintenance management, supply management,
procurement management, and financial management.
5-23
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
User workstations will be CGSWIIIs. ALMIS applications shall conform to standard Microsoft
GUI conventions. Users shall be able to select system colors, screen fonts, etc. The placement
of buttons, and other objects, shall conform to Microsoft GUI standards.
Support Personnel shall consist of the following:

System Administrators. The ALMIS servers (DEC 4100’s) shall be administered by
existing USCG Management Information Systems Division (MISD) and Maintenance
(O&M) contract personnel, but will require additional training for the RDBMS’ and
application development tools. ALMIS shall be designed to require no additional support
personnel through documentation, extensive context-sensitive help, and user training and
support.

Database Administrators. The ALMIS database shall be administered using existing
USCG ACMS/AMMIS system administrators and will require training for the new RDBMS’.

Help Desk Personnel. ALMIS users shall be supported by existing USCG MISD O&M
contract help desk personnel and a sophisticated help desk software system. The help desk
software shall eliminate the requirement for additional skill levels and reduce the need for
additional training of existing staff. A significant amount of effort will be required by the
ALMIS development team in order to ensure that the help desk software system is loaded
with the required information to support the ALMIS users and MISD O&M staff.
5.4.9 Training-Related Requirements
Training shall be specialized based on the ALMIS users’ expected involvement (role) with the
system. An ALMIS Training Plan shall provide detailed training requirement information.
5.4.10 Logistics-Related Requirements
The logistics-related objective shall be to provide maximum user availability with minimum
expenditure of USCG resources. ALMIS shall rely to the maximum extent possible on the use of
existing USCG support systems.
Logistics-related requirements such as system installation, training, configuration management, and
hardware and software support shall be addressed in the appropriate support documentation. All
ALMIS requirement documents and plans shall take into account all existing resources available to
the USCG. These documents shall be delivered during the design, development, implementation,
and maintenance support phases. ALMIS documents shall include, but are not limited to, the
following:






Software Development Plan,
Configuration Management Plan,
Configuration Management Procedures Manual,
Training Plan,
Training Schedule,
Installation Plan,
5-24
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description




Installation Schedule,
Software Transition Plan,
System Maintenance Manual, and
Data Conversion Plan.
5.4.11 Other Requirements
Most requirements for system documentation are specified in MIL-STD-498, including
specifications, drawings, technical manuals, test plans and procedures, and installation
instruction data. Other required standards that shall be used to a lesser extent are:







MIL-STD-973,
MIL-STD-1521B,
American National Standards Institute (ANSI)/IEEE Standards,
COMDTINST 5230.42A,
FIPS PUB 76,
FIPS PUB 183, and
FIPS PUB 184.
The ALMIS SDP and related planing documents shall be addressed in the appropriate detail and
be approved by Coast Guard representatives. The other requirements may include, but are not
limited to:








Testing requirement;
Training requirements;
System user and operator documentation requirements;
User and system support requirements;
Trasition requirements;
Installation requirements;
Workshop requirements, i.e., agendas, reviews, and minutes; and
Progress meetings, reports, and agendas.
5-25
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
6. OPERATIONAL SCENARIOS
This system shall support all facets of USCG Aviation logistics and operations. In addition to
Aviation managers having the ability to request ad hoc reports to support essential management
task, the following describes typical day-to-day types of ALMIS operations.
Flight Operations shall query the EIS to generate Air Station Performance Assessment Reports
including an operational statistics report which allows the Air Station to compare its operational
performance with that of the other Air Stations. They shall also query the DSS to automatically
calculate aircraft availability and dispatch rates. Flight Operations personnel shall routinely use
ALMIS to perform research and document normal daily tasks, including:



Personnel transfer and receipt,
Aircraft transfer and receipt, and
Flight data documentation, including itineraries, flight crew assignments and mission
results.
Maintenance managers shall query the EIS to generate statistical comparisons for maintenance
actions and the Monthly Operating Report (MORPT). They shall also query the DSS to verify
cannibalization rates for major aircraft systems and maintenance man-hours per flight hour for all
major aircraft systems. In addition the Air Station will routinely use ALMIS to perform research
and document normal daily tasks, including:







Scheduled and unscheduled maintenance actions,
Configuration Management actions,
Aircraft enrollment activities,
Coast Guard CG-22 submissions,
High-time component tracking,
Tracking maintenance activities, and
Producing Maintenance Procedure Cards (MPCs).
AR&SC Depot Maintenance managers will query the EIS to generate specialized production
statistical reports and graphics with which to brief USCG Headquarters representatives. They
will also query the DSS to automatically generate specialized component failure reports with
which to coordinate revision of Depot Maintenance processes with UCCG Aviation engineers.
In addition, Depot Maintenance personnel will routinely use ALMIS to perform research and
document normal daily tasks, including:





Work Order preparation,
Programmed Depot Maintenance documentation,
Component repair actions documentation,
Cannibalization actions documentation, and
Stock level evaluation.
6-1
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
AR&SC Engineering Services personnel will query the EIS to summarize Unsatisfactory Reports
for each aircraft Type and Model. They will routinely use ALMIS to perform research and
document normal daily tasks, including:



Reliability, Maintainability, and Availability management,
Manage Quality Assurance management, and
Time Compliance Technical Orders (TCTOs).
Air Station and AR&SC Financial Management personnel will query the EIS for specialized
budget reports. They will also query the DSS to automatically compare inventory value against
goals and projections. In addition, Financial Management personnel will routinely use ALMIS to
perform research and document normal daily tasks, including:








Ledger account transactions,
General Ledger management,
Funds Control management,
Disbursements management,
Receivables management,
Exchange financial information with the Large Unit Financial Systems (LUFS),
Personnel Services management, and
Industrial Services management.
AR&SC Procurement Management personnel will query the EIS to screen for funds availability.
They will also query the DSS to generate statistical reports in support of the Annual Procurement
Plan. In addition, Procurement Management personnel will routinely use ALMIS to perform
research and document normal daily tasks, including:




Purchase Request preparation,
Determining federal and commercial sources,
Process Requisition Requirements, and
Initiate Procurement Actions.
AR&SC Depot Supply personnel will query the EIS for backorder reports. They will also query
the DSS for supply prioritization effectiveness reports. In addition, Depot Supply personnel will
routinely use ALMIS to perform research and document normal daily tasks, including:






Exception management,
Backorder management,
Recommended Buys management,
Requisitions management,
Other Government Agency (OGA) Requisition modification, and
Technical Information management.
6-2
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
Air Station Supply personnel will query the EIS for inventory reports and to calculate the parts
consumption rate per flight hour. They will also query the DSS for supply prioritization
effectiveness reports. In addition, Depot Supply personnel will routinely use ALMIS to perform
research and document normal daily tasks, including:






Inventory management,
Parts Issue,
Repairable parts management,
Aviation inventory management,
Adjust Stock level adjustments, and
Parts shipping management.
6-3
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
7. SUMMARY OF IMPACTS
7.1 Operational Impacts
ALMIS will have a major impact on USCG Aviation operations at both local and enterprise-wide
levels. The numerous functional enhancements, modern ALMIS Relational Database
Management Systems, and employment of state-of-the-art data transmission and presentation
technologies will affect all USCG Aviation business areas. Included among the significant
operational impacts anticipated by ALMIS development are:




Source of Data Entry will be reduced by data sharing between the AMMIS Flight
Operations module and ACMS. Automatic flight hour calculation by AMMIS will
eliminate significant data modification requirements caused by flight time entry errors in
ACMS. The GUI will provide drop-down menus and reduce required text entry in many
cases.
The DSS and EIS will automatically provide numerous statistical and operational reports
currently generated on stand-alone computers or by hand. Additionally, the DSS and EIS
will reduce the need for manual data calls.
Performance Assessment, User Satisfaction, Quality Yield, and Ad Hoc reports will
provide local and enterprise management tools which will in turn enable fact-based
prioritization of USCG flight, missions, and operations.
Local and enterprise-wide trend analysis of inventory levels, unscheduled maintenance
and funds expenditure will provide managers the ability to better predict aircraft
availability, and ultimately, lead to greater levels of mission support.
7.2 Organizational Impacts
ALMIS will impact organization structure, including:




USCG representatives have estimated that Source of Data Entry will save the labor of 20
uniformed personnel in billets.
The DSS and EIS will provide powerful research tools to support data requests from
higher authority. This will result in a significant labor savings by virtually eliminating the
need to hand sort CG 4377 (Blue Sheet) forms to document cumulative operational
activities.
System support staff will require retraining for both OpenIngres 2.0 and Oracle 7.
However, both RDBMS’ feature powerful, modern development tools which will
ultimately reduce functional development time and effort.
Familiarization training will be required for ALMIS users because in the GUI
environment all user interfaces (screens) will be changed. The FLS Procurement and
Financial Management modules will probably result in minor business rule changes
which will require retraining for affected personnel. The FLS Supply Management
module is currently under development so the total extent of business rule changes, and
subsequent retraining requirements, is not yet known.
7-1
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
7.3 Impacts During Development
Users and support staff may experience significant impacts on time and resources during ALMIS
development. At the time of this writing, the following considerations apply:





Candidate data (for migration) must be identified and mapped to the new system’s
physical design structure prior to actual migration. Additionally, all required data
validation and cleansing must be completed. The degree of required data cleansing is not
clearly defined at this stage and could have and impact on cost, schedule and risk if
significant data cleansing is required. Failure to perform these functions can result in
incomplete data transfer to the new system or population of the new database with invalid
or corrupted data.
Another possible impact for ALMIS development and implementation concerns the
availability of new CGSWIII computers (to replace CGSWII machines) in time for
ALMIS installation. ALMIS implementation at the various facilities must be coordinated
with the CGSWIII implementation schedule to ensure users have access to hardware that
will be capable of operating ALMIS. Because ALMIS will be implemented in a GUI
environment and the CGSWII operating system (CTOS) will not support a GUI, the
ALMIS would be unavailable to users still using the CGSWII machines.
User and support staff personnel training must be completed prior to ALMIS installation
at each facility. The ALMIS training strategy is to train everyone according to varying
levels of need. Failure to complete ALMIS user and support staff personnel training prior
to ALMIS implementation will prevent full system use and reduce the ability to perform
organic system maintenance.
Redesign of the Flight Operations module and subsequent migration to the OpenIngres
2.0 environment is not complete. Incomplete redesign or incomplete data migration will
prevent ALMIS from fully supporting Flight Operations business area functions.
The FLS Supply, Procurement, and Financial Management modules are not complete.
Initial Operating Capability (IOC) for FLS is schedule for September 30, 1999. Failure to
meet the IOC date will impact the ability of USCG Aviation to transition to ALMIS on
schedule.
7-2
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
8. ANALYSIS OF THE PROPOSED SYSTEM
8.1 Summary of Advantages
Advantages of the ALMIS include:








After application of all assumptions and constraints, this system design was awarded the
highest technical score of all viable alternatives, and was selected as the “best choice” to
fulfill ALMIS objectives and replace the legacy ACMS/AMMIS systems.
The use of FLS modules (no initial development cost),
ACMS and the ALMIS Flight Operations module will use a more powerful version of the
Ingres RDBMS (CA-OpenIngres),
Addition of Decision Support System and Executive Information Systems capabilities,
Graphical User Interface,
Internet telecommunications technology,
WWW technology which will give authorized users access to FLS, and
WWW technology which will give authorized users from other systems access to ALMIS.
8.2 Summary of Disadvantages/Limitations
Disadvantages of the ALMIS include:





FLS modules have not yet reached IOC,
Added cost to maintain two RDBMS systems,
Many of the high priority requirements specified in the ALMIS Strategic Analysis Report
will not be developed, including the Coast Guard Headquarters module,
ALMIS does not use distributed data which makes it dependent on external
communication interfaces (potentially reducing system availability), and
Ad hoc query limited by ALMIS physical structure (ALMIS and FLS databases).
8.3 Alternatives and Trade-Offs Considered
ALMIS analysis objectives and requirements define the need, the user, and the availability of
resources bounding the scope of the analysis. These were defined in the ALMIS Strategic
Analysis Report, Version 2.0, dated May 13, 1997.
Alternatives reflecting a wide range of distinctly different solutions were selected by the ALMIS
Management Team during the Strategic Analysis phase of the ALMIS BAA, with the overall
goal of optimizing the system design. Alternatives were described in detail sufficient enough to
enable the team to judge the relative worth of each. ALMIS alternatives that were first defined
and approved in the SAR, further evolved through an iterative process during meetings of the
USCG/OAO ALMIS team at OAO Headquarters in Greenbelt, MD.
A description of the eight major alternatives considered for ALMIS, the trade-offs among them,
8-1
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
and rationale for the decisions reached may be found in the ALMIS Business
Process/Information Systems Comparative Analysis Report (CAR), version 2.0, dated November
7, 1997.
8-2
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
9. NOTES
9.1 Terms and Definitions
Table 9-1 provides explanations and definitions of the terms used in this document.
Table 9-1. Terms and Definitions
Term
Definition
Data Cleansing
The checking, validating, and updating of a database. This process
removes inactive and erroneous data and consolidates duplicate records.
This is usually performed using a commercially available data cleansing
software application specifically designed for this purpose.
Database Linking
In database linking, common elements of two or more databases are used
to “link” the databases for interoperability within an application. This
makes it possible to use one source of data entry because the data tables
are cross-referenced. This practice helps to ensure data accuracy and
commonality across the application.
9.2 Acronyms and Abbreviations
Table 9-2 provides a list of acronyms and abbreviations used in this document.
Table 9-2. Acronyms and Abbreviations
Acronym/
Abbreviation
Expansion
A0
Operational Availability
ABL
Allocated Baseline
ACMS
Aircraft Computerized Maintenance System
AIS
Automated Information Security
ALMIS
Aviation Logistics Management Information System
AMMIS
Aviation Maintenance Management Information System
ANSI
American National Standards Institute
AR&SC
Aircraft Repair and Supply Center
ASCII
American Standard Code for Information Interchange
ATES
Aircraft Troubleshooting Expert System
BAA
Business Area Analysis
BPI
Business Process Improvement
BPR
Business Process Reengineering
9-1
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
Acronym/
Abbreviation
Expansion
CAR
Comparative Analysis Report
CM
Configuration Management
COCOMO
Constructive Cost Model
CPU
Central Processing Unit
CRUD
Create, Read, Update, or Delete (user permissions for entities)
CSCI
Computer Software Configuration Item
DAFIS
Departmental Accounting and Financial Information System
DBDD
Database Design Description
DEC
Digital Equipment Corporation
DSS
Decision Support System
DTI
Data Transfer Integrity
ECP
Engineering Change Plan
EIS
Executive Information System
ERD
Entity Relationship Diagram
FBL
Functional Baseline
FLS
Fleet Logistics System
GOSIP
Government Open Systems Interconnection Profile
GUI
Graphical User Interface
HW/SW
Hardware/Software
HWCI
Hardware Configuration Item
IDD
Interface Design Description
IDEF
Integration Definition for Function Modeling
IEEE
Institute of Electrical and Electronics Engineers
IOC
Initial Operating Capability
IRS
Interface Requirements Specification
IRUN
Input, Read, Update, or Null (user permissions for attributes)
ISTA
Information Systems Technology Architecture
LAN
Local Area Network
LUFS
Large Unit Financial Systems
MISD
Management Information Systems Division
MLDT
Mean Logistics Delay Time
MORPT
Monthly Operating Report
MPC
Maintenance Procedure Cards
9-2
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
Acronym/
Abbreviation
Expansion
MSR
Mandatory Special Requirement
MTBF
Mean Time Between Failure
MTTR
Mean Time to Repair
O&M
Operations and Maintenance
OGA
Other Government Agency
PMIS
Personnel Management Information System
POSIX
Portable Operating System Interface for Computer Environments
QA
Quality Assurance
OCD
Operational Concept Description
QNM
Queuing Network Model
RCM
Reliability Centered Maintenance
RDBMS
Relational Database Management System
SAR
Strategic Analysis Report
SDD
Software Design Description
SDP
Software Development Plan
SLCM
Software Live Cycle Model
SLCMP
Software Life Cycle Management Plan
SNT
Serial Number Tracked
SOP
Standard Operating Procedure
SQL
Structured Query Language
SR
Special Requirement
SRS
Software Requirements Specification
SRS
System Requirements Specification
SSDD
System/Subsystem Design Description
SSS
System/Subsystem Specification
STD
Software Test Description
STE
Software Test Environment
STP
Software Test Plan
TCTO
Time Compliance Technical Orders
TR
Trouble Report
UFI
User Friendly Interface
USCG
United States Coast Guard
V&V
Verification and Validation
9-3
Z071d07a.doc
Version 1.1
11/11/1997
ALMIS Operational Concept Description
Acronym/
Abbreviation
Expansion
WAN
Wide Area Network
WS III
Work Station III Computer
WWW
World Wide Web
Y2K
Year 2000
9-4
Z071d07a.doc
Version 1.1
11/11/1997