As this task involves close interaction with the Office of the
Secretary of Defense (OSD), DLSC, CECOM, and AFMC, we have been
continuously interacting with personnel from these organizations.
Coordination efforts have also been made with PRC which is in
charge of the development of the DLSC Information Hub. When Task
2 of the present contract was established, it was done so with
the understanding that there is an automated system of processing
DD Form 61s which is used at both CECOM and AFMC. This was later
recognized as false at both sites. In summary, no automated system
exists at CECOM or AFMC; no network infrastructure exists specifically
for the type designation system; legacy data exists on various
media with duplications and much of the data is of poor quality.
Therefore, instead of developing a plan of constructing only
the relational database, telecommunication, and prototype testing
of the connectivity to the Defense Logistics Services Center (DLSC)
Information Hub, we are planing to build a new TDAS for both sites.
Throughout the early phase of the task, the information has been
gathered on the current CECOM and AFMC environment and process,
expectations of the TO-BE system, and difficulty of legacy data
conversion. After preliminary analysis, assessment, and evaluation,
we have developed this POAM for constructing the TDAS.
Section 1.0 of this document identifies the purpose of this document,
the preliminary assessments and initial findings for a type designation
system at CECOM and AFMC. The focus of this report is Section
2.0. This section details the construction of relational database,
telecommunication, and prototype testing as described in the original
task description. It also highlights one major issue: the development
of a Concept of Operations (CONOPS)/functional requirements for
a TDAS. It further presents a preliminary system architecture
of a TDAS and lays out the choices and alternatives for required
software modules and equipment and approaches. Finally, the report
is concluded with a summary in the last section.
Enabling of the communication and query response between DLSC
Information Hub and CECOM/AFMC. This will allow a DLSC Hub user
to be able to query upon CECOM and AFMC databases through the
unified user interface at the DLSC Hub.
Development of Type Designation Automated Systems at CECOM/AFMC.
This phase is to automate the current CECOM/AFMC manual process
and also to enable the DD Form 61s to be submitted electronically.
Please note, a query initiated from CECOM or AFMC to DLSC Information
Hub is not in the scope of this task, therefore, it is not planned
in either phase. In fact, the DLSC Information Hub is supposed
to fulfill such query through the uniform DLSC interface when
a user needs to perform cross-reference to other type designation
systems. However, the crossreference capability can be
achieved by augmenting the planned TDAS and the discussion will
be included in the CONOPS in the future.
The following is the list of action items and milestones that
have been identified. The approaches that will be taken and the
importance placed upon them are discussed in the following sections.
It has been recognized that many projects fail because of insufficient
analysis and definition. For example, some projects as envisioned
are simply not feasible. Other projects are possible, but not
within the framework of time and money allocated. Some projects
are so vaguely defined that developers cannot understand requirements
or define when they have been met. Therefore, it is important
that a complete analysis and definition is done at the early stage
of the project.
There are several significant actions which will be accomplished
during this analysis and definition stage, including requirement
analysis, trade-off analysis, and preliminary system design.
Information will be obtained from all parties involved in order
to develop a concept of operations and a functional requirements
document. This will clearly describe our vision of a Type Designation
Automated System so all parties involved - OSD, DLSC, CECOM, and
AFMC - will clearly understand our development direction.
This CONOPS will not only focus on the implementation of CECOM
and AFMC TDASs, but will also provide a blueprint for automating
other manual Type Designation Systems within the Department of
Defense (DoD) in terms of construction of each system and collaborations
among systems. The preliminary outline of the CONOPS includes:
Distributed processing and database configurations have evolved
through a number of stages from host-based processing to master-slave
processing and, finally, client/server computing and World Wide
Web (WWW) application. These two techniques will be used to serve
both internal TDAS users (a.k.a. super-client personnel of CECOM
and AFMC who are responsible for DD Form 61s processing) and external
users (a.k.a. client who currently submits DD Form 61s through
the mail), respectively. The preliminary system architecture
is illustrated in Figure 2.2-1.
Advantages of client/server computing include:
One of the most significant benefits of a WWW approach is the
elimination of the software installation and managing problem.
There is a tremendous cost in terms of person hours and money
necessary to install software on hundreds of users of CECOM and
AFMC. The process and cost will be repeated whenever there is
any software update. Therefore, the WWW approach is attractive
and cost-effective to support external clients. Although the
Internet is having access, capacity, and performance problems
from time to time, it is still a preferable choice after the trade-off
consideration. Nevertheless, the network access will be closely
monitored and these concerns will be addressed when the system
is in operation.
Two different levels of users of TDAS have been identified: super-client
and client. Superclients are CECOM or AFMC personnel who
are responsible for DD Form 61s processing. Because they need
to approve or reject DD Form 61 requests, generate various reports,
and perform other tasks to support their day-to-day functionality,
they will be given greater access privileges to the database system.
On the other hand, clients are those (including government agencies
and contractors) who submit DD Form 61 requests to CECOM or AFMC.
In addition to those requests, they often need to inquire information
from the type designation system regarding, for example, nomenclature,
part number, or Commercial and Government Entity (CAGE) code.
Most of their requirements are to perform inquiries, therefore,
they will be given restricted access to the database. Furthermore,
because these two roles have different responsibilities, the user
interface and application will be tailored to meet each requirement.
More likely, a client application will only have a subset of
functionality of what a super-client will have.
The database design will follow the American National Standards
Institute/Standards Planning and Requirement Subcommittee (ANSI/SPARC)
three-schema model. The three schemas are:
One major advantage of the approach is the improved data independence.
When interacting with a Relational Database Management System
(RDBMS), client applications are relatively independent of the
actual data in the database. This means that many changes to
the structure of the data itself may not require maintenance to
existing client applications. In addition, because the low-level
data manipulation is handled by the RDBMS, details concerning
this manipulation do not appear in applications. Without such
independence, changes to the database structure to improve performance
and to meet changing organization requirements become very difficult.
Obviously, a client application would need to be changed if some
fields that it required were deleted from the conceptual schema.
The important point is that the conceptual schema could change
(fields added, relationships added, formats changed) without affecting
the external schemas. Similarly, an internal schema can be changed
without affecting the conceptual schema. The changes made to
the internal schema to improve the performance of the database
would not change the external schemas (subject, of course, to
the stipulation that the data they require is still present in
the new structure). In this way, the data independence is achieved.
A data dictionary will be developed which contains the descriptive
information about the data stored in the database. For each data
field, a data dictionary will contain the descriptions of:
The database schema represents the programmer's view of the database.
By using an advanced modeling tool, such as ERWin from Logic
Works or S-Designor from PowerSoft, it can be generated directly
from an Entity-Relationship (E-R) diagram. This will save many
person hours in writing the schema. Any schema change is then
a simple matter of redrawing the E-R diagram. Furthermore, once
the schema has been generated automatically by such a tool, the
schema can be loaded into the RDBMS to generate the actual tables,
relationships, and associated constraints.
There are many concerns in terms of building a successful database
system. Although some of the concerns can be overcome by today's
advanced RDBMS, there are still critical issues that require proper
design and implementation. For example, to eliminate data entry
error, data validation and verification will be embedded into
the schema design whenever it is feasible.
Finally, the schema will not only support the response to the DLSC query but will also be tailored to support both CECOM and AFMC daily functions regarding DD Form 61s processing. Because CECOM and AFMC may have different needs, slight variation is possible and anticipated. However, the core of the schema will remain the same for all TDASs.
The client and super-client applications will have a GUI. The
interface will be intuitive and userfriendly. The user's
needs (both super-client and client) will be thoroughly considered
throughout the entire design and implementation processes. The
goal of the GUI is to provide a frond-end so that a new user with
basic word processor or spreadsheet experience will be able to
use the application with minimal training required. Several guidelines
that will be used and implemented in the GUI are described in
the following sections.
The GUI design will focus on what is best for CECOM and AFMC users,
rather than what is quickest and easiest to implement. Design
reviews will be held periodically with both CECOM and AFMC to
ensure that the final GUI will be acceptable to their users.
Consistency is one of the most significant factors affecting usability.
Typically, users expect certain aspects of an interface to behave
in a certain way. When that does not happen, it can be very confusing.
We will emphasize consistency within the GUI operation and appearance
during our development.
Effective feedback has a significant impact on the users. Via
proper feedback, users can gauge the effects of their actions.
For example, once a record has been deleted, a message should
be displayed notifying the user that the record has actually been
deleted.
In addition, the message will be in a user-centered wording style
because the sole purpose of a message is to communicate with the
user. The wording of the message will be carefully selected by
using positive, constructive, and non-threatening wordings. A
user may already know they are in trouble when there is an error
message and the last thing the user needs is to feel chastised
or punished by the system when seeing a message such as "fatal
error, notify the system administrator."
As described in Section 2.2, the telecommunication has to support
both super-client and client. Because the preferred choice of
RDBMS, Oracle, is capable of supporting a wide variety of network
protocols, whatever protocol used by the current Local Area Network
(LAN) at CECOM or AFMC will continuously be used to support the
internal super-clients. For external clients, the WWW-enabled
application is a highly feasible approach. Not only does it eliminate
the repeated cost for software installation and updating, it
also reduces CECOM and AFMC difficulties of supporting various
network protocols that may be used by those clients.
Internet is built on Transport Control Protocol/Internet Protocol
(TCP/IP) which is the most widely available protocol today, thus
users will have no problem acquiring it. There are several common
mechanisms of acquisition, including the direct connection through
a LAN router that connects to the Internet or through any dial-up
service, either from government agencies or a commercial Internet
Service Provider (ISP).
The connection between the DLSC Information Hub and CECOM/AFMC
will depend on the requirement set up by the DLSC. At the present
time, TCP/IP has also been initially identified as the protocol
choice by DLSC through the Logistics Remote Users Network (LOGRUN).
Therefore, no additional communication infrastructure is planned.
One tough decision we made here is the usage of the WWW/Internet
to support external clients. We are fully aware of the potential
problems of the Internet and the frustrations it incurs to users,
however, it is still our planned approach after thorough considerations.
As mentioned earlier, it eliminates the repeated software updating
and installation costs as well as the supporting cost that will
be necessary to both CECOM and AFMC if using other mechanisms.
Based upon CECOM statistics, the average number of DD Form 61
requests is about 15 per day (AFMC has fewer requests). For this
workload, the occasional WWW/Internet problems will not be highly
noticeable and, thus, we will be able to take advantages of its
low-cost and open system concept. Nevertheless, the access will
be closely monitored and concerns will be addressed when the system
is in operation.
The difficulty of legacy data conversion is detailed in the assessment
report which is being delivered concurrently, so we will not reiterate
here. In short, the legacy data is stored in various media and
much of the data is of poor quality. It is also realized that
all of the data need to be converted and loaded into the database
in order to support the processing. It is our intent with the
help from CECOM and AFMC to convert as much valid legacy data
as possible within the budget constraint. A table of legacy data
and conversion cost on various media is illustrated in Table 2.6-1.
| Cannonfile |
|
Total: ~$6,225.
|
|
| Text/Paper |
|
Total: $1150.
|
|
| Microfiche |
CECOM: 75K pages (1982 - 1986). Not DD Form 61s, but has key data. Canada 1951 to 1992. |
Total: $11,500
|
|
| Microfilm |
|
|
|
| 9 Track tape |
|
|
|
A ledger book is being used in both CECOM and AFMC which shows
the history of all nomenclatures ever assigned and next available
nomenclature in sequence. For CECOM alone, the ledger book consists
of about 200 volumes of three-ring binders. The use of the ledger
book is not only time-consuming, but also could be hazardous because
this ledger book is the only copy that exists. Therefore, we
plan to eliminate the ledger book by capturing all the valid legacy
data. With all the data in the database, the history of a nomenclature
or next available nomenclature in sequence can be easily obtained
by a simple query to the database.
The prototype testing consists of two phases in accordance with
the two-phase implementation plan as described in Section 2.0.
The first phase is to test the connectivity between CECOM/AFMC
and the DLSC Information Hub. A small portion of the legacy data
will be converted and loaded to the database in order to respond
to the query from the DLSC Information Hub. There are several
key components that will be evaluated, including database schema
design, installation of Enterprise Data Access (EDA)/Structure
Query Language (SQL), and telecommunication.
The second phase focuses on the TDAS itself. We will develop
integration testing procedures, system testing procedures, and
baseline performance metrics for CECOM and AFMC. Test procedures
will be developed for each program module and for the integrated
systems. These procedures will be used to evaluate the performance
of the modules and the system during this subtask. The test procedures
will delineate the tests to be performed, the type of test data
to be used, the procedures for creating the test data, and the
characteristics to be measured. Legacy data will be used for
the performance testing. The various testing stages are illustrated
in Figure 2.71.
A test analysis will be prepared that may include findings, conclusions,
and recommendations resulting from these tests in the areas of
the RDBMS design, telecommunications, and feedback from users.
Given the preliminary analysis and budget constraints of the task,
the following products have been initially chosen for consideration.
The final selection will be determined during the actual procurement
process.
| ANSI/SPARC | American National Standards Institute/Standards Planning and Requirement Subcommittee |
| AFMC | Air Force Material Command |
| ASCII | American Standard Code for Information Interchange |
| CAGE | Commercial and Government Entity |
| CECOM | Communication and Electronic Command |
| CONOPS | Concept of Operations |
| DoD | Department Of Defense |
| DLSC | Defense Logistics Service Center |
| EDA/SQL | Information Builders, Inc. Enterprise Data Access/Structure Query Language software product |
| E-R | Entity-Relationship |
| GUI | Graphical User Interface |
| ISP | Internet Service Provider |
| JETDS | Joint Electronic Type Designation System |
| LAN | Local Area Network |
| LOGRUN | Logistics Remote Users Network |
| OCR | Optical Character Recognition |
| OSD | Office of the Secretary of Defense |
| POAM | Plan of Actions and Milestones |
| RDBMS | Relational Database Management System |
| SCSI | Small Computer Systems Interface |
| TCP/IP | Transport Control Protocol/Internet Protocol |
| TDAS | Type Designation Automated System |
| WWW | World Wide Web |