TABLE OF CONTENTS

   

LIST OF FIGURES

LIST OF TABLES

1.0  DEMONSTRATION INTRODUCTION

2.0  CONVERSION DEMONSTRATION SETUP

3.0  CONCEPT OF OPERATION DEMONSTRATION

4.0  CONCLUSIONS

APPENDIX A:  ETM/IETM CONVERSION PROJECT COSTING MATRIX

APPENDIX B:  ETM/IETM CONVERSION PROJECT PROJECTED PRICING CHART

APPENDIX C:  ETM/IETM CONVERSION PROJECT STEP SUMMARY TABLE

APPENDIX D:  IETM CONFORMANCE ESCORT (ICE) DEMONSTRATION REPORT

APPENDIX E:  MODIFIED MIL-D-87269 DTD

APPENDIX F:  AUTOMATED TAGGING SCRIPTS

LIST OF FIGURES

      

Figure 2.3-1  Configuration Management Baseline Control Directory Tree Structure

Figure 3.0-1  General Conversion Process

LIST OF TABLES

      

Table 3.2-1  Technical Manual Sampling

List of Acronyms

      

      

The Resource critical information area of the Continuous Acquisition and Life-cycle Support (CALS) initiative provides technical information to weapons system operations and maintenance personnel. The relevant technologies deal with the authoring, migration, delivery, and maintenance of technical information for both new weapon systems and legacy weapon systems. A critical issue is how best to migrate the voluminous paper-form technical manuals on current weapon systems to interactive, electronic technical manuals that reduce the labor-intensity for the authoring, maintenance, and delivery of technical information.

It is well known that the volume of paper-based technical manuals, engineering drawings, and documentation associated with any complex amalgamation of weapon systems (i.e., a ship) can be measured by the tonnage. Converting these documents from paper to an electronic form has been shown to reduce (a) cost in producing the documents, (b) storage requirements, and (c) cost of maintaining and updating the electronic form once it has been converted.

ManTech has been contracted through the Integrated Data Environment (IDE) contract to design a standards-based approach for legacy data conversion to Electronic Technical Manuals (ETMs)/Integrated ETMs (IETMs) constructs. This type of approach would help avoid the proliferation of electronic formats and would facilitate data interchange among dissimilar automated systems. The result of this design has taken the shape of a Concept of Operation to be used by Conversion Services in the Department of Defense (DoD). This conversion service concept document has addressed the general conversion processes involved, techniques used, specifications and standards that may be required, possible risks involved, how to provide a projected cost for a conversion project, and other requirements associated with the conversion effort.

The goal was to define what general conversion processes and support activities would be required for a conversion service, and how they would function. The term process or processes was defined as a series of progressive and interdependent steps by which an end is attained. In this case, the end attained would be the completed ETM/IETM system.

The Concept of Operation report was written so that it can be adapted easily to any technical manual conversion project. The conversion processes were designed so that no matter what types of data the user starts with and what type of ETM/IETM desired, the general conversion process steps would be the same. The only differences between processes of the different class requirements would be how the process is accomplished, not what the process is.

The purpose of this report is to document in detail our proof of concept for the designed general conversion process and the overall conversion service organizational behavior.

1.1  Purpose of the Demonstration

The purpose of this demonstration is to use the class 2/3 constructs to demonstrate the defined concept of operation for ETM/IETM conversion. The demonstration focused on constructs that enable the user to browse through text and graphics using hypertext hotspots and to gain interactive presentation of maintenance information through the use of dialog-driven displays. This demonstration included estimated cost for conversion and the use of the general conversion process as defined in Section 3.0 of the IETM Conversion Service Concept of Operation developed for the DOD CALS IDE Project. This demonstration provides proof that the general conversion process as defined can work for all class conversion.

1.2  Description of this Report

This report contains the steps our team performed during the conversion demonstration setup (Section 2.0) and the steps performed within each conversion process in order to demonstrate our concept design (Section 3.0). Section 3.0 includes a description of the process that was performed, steps that where taken, the man-hours used, suggested personnel for each process, issues that arose during the process, and the steps taken to resolve those issues. Section 4.0 contains our final conclusion to the demonstration itself, problems we encountered, how we resolved those problems, and suggestions to enhance the selected software and conversion concept design.

2.0  Conversion Demonstration Setup

      

Prior to any conversion project, several managerial activities must take place. Quality Assurance (QA) and Configuration Management (CM) teams must be organized and procedures set in place to efficiently manage each individual conversion job. The project management must establish the conversion team and set up the accounting requirements to properly monitor the conversion budget.

In our demonstration, one additional activity took place prior to the start. As in all technical manual conversion projects, a technical manual is required. Our team developed a list of requirements that would demonstrate a wide variety of conversion efforts. We required our selected manual to have at a minimum text, tables, graphics, page combination (i.e., text/graphics, test/tables, all three), and a Table of Contents. This manual will also need to be limited in page count so that the entire manual could be converted in the given project time frame. Our team visited the West Virginia University Government Depository Library to locate such a manual.

A manual containing all of the above requirements was located and used for this demonstration. The manual chosen was the Technical Manual Organizational, Direct Support, and General Support Maintenance Manual including Repair Parts and Special Tools Lists (including Depot Maintenance Repair Parts and Special Tools) for the Night Vision Goggles AN/PVS-5 and AN/PVS-5A (NSN 5855-00-150-1820) TM 11-5855-238-24&P. This manual was chosen not only because it contained a wide multitude of graphics, tables, fonts, and text that could be considered possible problems when using automated conversion tools, but also becaused it exercised a number of possible conversion situations.

2.1  Project Management Setup

During the initial setup period, project management would begin filling out the costing matrix for the conversion project. It is important to establish and document as many requirements as possible prior to the start of an actual conversion project. The Statement of Work (SOW) should provide the functional requirements for the ETM/IETM and the contractual requirements that must be followed.

The costing matrix that would be completed is divided into three parts. Part one documents such areas as customer information, source media, and delivery media. Part two when completed will provide basic information about the conversion project itself. These two areas should be completed during the setup period. This information would aid in the development of the conversion team and establish requirements in the area of hardware and software that may need to be purchased.

Part three of the costing matrix may require further research in the areas of (a)  the data within existing technical manual, (b)  the functional requirements of the desired ETM/IETM, and (c)  the complexity of the conversion effort. This along with the projected pricing chart may not be finished until after the first three conversion processes have been completed. If any software purchasing and/or DTD designing is required, the matrix and project cost documents would not be completed until after process four [Select Authoring/Viewing Software and DTD(s)/Schema(s)].

For our demonstration, part three of the costing matrix (Conversion Effort) and the projected pricing chart were not completed until after the ETM software and the automated conversion tools were selected. Paragraph 3.4  Select Software/DTD describes the selection of software and the reason for that selection. Appendix A contains the completed ETM/IETM Conversion Project Costing Matrix, and Appendix B contains the completed ETM/IETM Conversion Project Projected Pricing Chart. It is important to note that the price per unit and unit count are fictitious and can be changed using Microsoft Excel.

2.2  Quality Assurance Setup

During the setup period, the Quality Assurance team would gather all standards and specifications required by the conversion project contract and Statement of Work. In addition to the required ETM/IETM documentation, the QA team would also prepare their Quality Assurance plan documenting the particular test requirements for the conversion project and the step-by-step procedures that will be followed during the life span of the contract. This may include special quality check matrices, project setups for the Conformance Validation procedures, and identifying all special materials required for the preparation and delivery of the final product.

The initial setup requirement for the Conformance Validation procedures would include the capability to access the World Wide Web (WWW). The validation procedures for levels 0 through 6 are maintained at location http://galaxy.mantech-wva.com/ice/qualify/int_page.html. When this location is entered into an Internet browser, the IETM Conformance Escort (ICE) Demonstration screen would be displayed. This IETM Conformance Demonstration will be used during the seven layers of conformance validation processes that occur throughout the conversion project. The steps taken during the validation processes are documented throughout Section 3.0, and the final report documenting the validation results is provided in Appendix D.

The ICE Demonstration provides information on a standard and modular methodology for (1)  screening IETM programs, (2)  interactive guidance for administering conformance testing of IETM deliverables, and (3)  a method for measuring and reporting the degree of conformance within the architectural framework model.

2.3  Configuration Management Setup

During the setup period, the Configuration Management team would set up the directory structure to monitor and control the flow of work and baseline all data files and software generated during the conversion effort. The data and/or conversion code would pass through the QA department for the different stages of validation and verification prior to the baseline procedures by CM. Once QA is satisfied with the quality of information contained in the files, these files would be passed to CM to be placed in their appropriate baseline directory. The following figure is a sample DOS TREE structure for those baselines.

The Technical Manual Baseline (TMBL_ARM) main directory contains the electronic version of the technical manual. These data would either be the in-house converted files or the customer’s electronic files (Word, WordPerfect). The data would be placed in the respective sub-directory (text or graphic).

The Tag Data Baseline (TAG_DATA) was used as the working directory that contains the tagged text, graphic Bitmaps with their associated Picture Definition Files (PIC), and all style sheet files used for the developed ETM/IETM system. This working directory would also contain any automated tagging files such as the FastTag Louise and Inspect script files used for the automated tagging process and the C++ software developed to further enhance the automated process.

The Production Baseline (PRBL_ARM) main directory contained the actual ETM/IETM system (ARMY_ETM) and all conversion code (ARM_CODE) designed primarily for this conversion effort. The production baseline will not be occupied until the ETM/IETM system has passed all QA Validation and Verification check points.

The Customer Baseline (CUSBL_AR) main directory contained the delivered customer accepted ETM/IETM system (ARMY_DEL). Stored along with this delivery will be the developed conversion code (ARM_DLCD) used during the project. This code is being stored for future conversion efforts that may pertain to the specific TM.

3.0  Concept of Operation Demonstration

      

When considering converting between Types or Classes of paper or electronic technical manuals, the conversion process is much more than simply a set of procedures for data translation. The conversion process must begin with an in-depth evaluation of the Type or Class of technical manual that is most suitable, both functionally and economically. The economical considerations are very important because, depending on the desired target data type, there can be significant differences in the level of expertise, the amount of time, and hence the cost required to carry out the conversion process. It is important to note that when converting to non-page-based electronic formats, even if the desired target data type consists of SGML files, the conversion service must consider how that data will be both authored and presented.

It is important to understand before any conversion process takes place that the philosophy of "one size fits all" does not apply in the ETM/IETM world. Every system has the possibilities of being different because of the functional requirements established by the customer, the data being converted, the environment the system will be used in, and the end-user's knowledge and capabilities using it.

The alternative to establishing precise conversion procedures for all different implementations is to define a general approach that deals with those aspects that does not depend on the format of the data or the electronic presentation system that is used. After detailed analysis, it has been determined that no matter what types of data the user starts with and what type of ETM/IETM system the user desires, the general conversion process steps are the same. The only differences between processes of the different class requirements are how the process is accomplished, not what the process is.

Using Figure 3.0-1 General Conversion Process as our guide to what processes and steps must take place in a conversion project, the following section documents how the processes and steps were performed. The following paragraphs will describe the steps our team had taken, any issues or problems that were encountered, and the solutions to those areas. Each conversion process also will contain a list of suggested personnel for that process and the length of time utilized by our team performing the actual work. Appendix C contains a summary table of the Steps, Suggested Personnel, Our Total Time, Problems encountered, and their solutions.

3.1  Determine Functional Requirements

As stated above, every ETM or IETM system has the possibility of being different. The differences are due to the requirements established by the customer, the data being converted, the environment the system will be used in, and the end-user’s knowledge and capabilities using it. Defining the functional requirements and having all parties in full agreement on the design, conversion, and final implementation are the corner stone of any developmental project.

After establishing the management guidelines and the QA and CM team structures, our team began analyzing the SOW sub-task requirements for the type of system required. The SOW under Task 8, sub-task 4 requires that we must "demonstrate use of the ETM/IETM conversion service concept in conjunction with a selected defense program, and provide support for conversion of legacy data to class 2/class 3 constructs." However, because of the time constraints with this project, we performed the demonstration in-house by following the concept of operation design. In addition, it was documented in ManTech’s Management Plan that this sub-task would be using the ManTech defined ETM/IETM class definitions.

The following describes the functional requirements, as defined by our team, that were used in the design of our MB+/MC ETM system.

Recommended Personnel for this Process:  Customer, Conversion Group

Our Time:  10 hours

3.1.1  Functional Requirements

The following describes the function requirements, as defined by our team, that were used in the design of our MB+/MC ETM system.

3.1.2  Additional Conversion Project Requirements

In additional to the basic functional requirements for our ETM, we included several additional project requirements. These requirements are considered outside the boundaries for the basic MB+ ETM system:

1. Reformat the troubleshooting tables to dialog discussion tree logic that can be traversed.

 

2. During QA content reconciliation, correct errors detected with the spelling of words within the originally supplied TM.

 

3. Use a standard MIL-D-87269 DTD if possible.

 

4. Use an automated tagging tool to decrease cost and expedite the tagging and conversion process.

 

5. Try to use an MIL-M-87268 Government Off The Shelf (GOTS) or Commercial Off The Shelf (COTS) ETM/IETM system to reduce customer cost.

 

6. Ensure that all SGML tagged files parse.

 

7. Include these items with final delivery:

1. Converted text (.TXT) and graphics (.BMP) data files;
2. Parsed SGML Tagged (.INI) files;
3. Picture Definition (.PIC) files;
4. Modified MIL-D-87269 DTD (.DTD);
5. Authoring/Viewing Software Package with all licensing agreements required; and
6. Automated Conversion scripts and code.

3.2  Gather Samples

Samples of the document, whether paper or electronic, are required at the onset of any conversion project to accurately gauge the quality and complexity of the product being converted. These samples were used in the preliminary document analysis process, DTD development/selection, and mapping process. The samples should include, at a minimum, examples of text, graphics, tables, and any other unique items contained within the document. Several pages from our selected government technical manual were gathered for our samples. The following table details the pages used and why they were selected:

Recommended Personnel for this Process:  Customer, Document Analyst

Our Time:  1 hour

3.3  Preliminary Document Analysis

The preliminary document analysis process is the activity that would identify, analyze, and address all issues involved with the document design. The process also provides the understanding of all uses of the information contained in the technical manual and identifies all components of information needed to support an organization in order for it to complete its mission.

At the begin of this process, the samples gathered were individually scanned and OCRed. After reviewing the contents of the resulting ASCII files, it was determined that all tables would need to be entered manually because of the enormous number of errors during the character recognition, (e.g., 5 became S, I became 1, 8 became B, columns were lost). The tables would be typed in using a Text editor (NotePad).

The other pages containing text only, graphics only, and text with graphics previewed sufficiently to allow the scan/OCR process to continue in these cases.

During the preliminary document analysis process, the team broke down the contents within the technical manual. These contents were listed and further broken down into elements and sub-elements. Once this step was completed, decisions on how they related to each other and how the elements would be represented were made. This information was used to determine the appropriate DTD and authoring/viewing software for our ETM system and to define the mapping requirements of source to selected DTD.

Recommended Personnel for this Process:

(Preliminary Scan/OCR:  Data Entry)

(Preliminary Document Analysis:  Conversion Group)

Our Time:  

(Preliminary Scan/OCR:  15 minutes)

(Preliminary Document Analysis:  8 hours)

3.4  Select Authoring/Viewing Software and DTD

At this point of the conversion process, several major decisions must be made. The selection of the DTD or Scheme used in the creation of the ETM/IETM in conjunction with the authoring and viewing software is dependent on the results from the defined functional requirements and the preliminary document analysis.

Because the technical manual belonged to the Army and because an ETM system (IADS)existed already, we started our software research with them. We began reviewing first the functional requirements defined in 3.1 above, then the list of elements that made up the technical manual defined in 3.3. We then reviewed the functional capabilities of the Army’s IADS system version 2.2 and accompanying DTD. It was determined that the software paired up with the functional requirements defined. The DTD supplied with IADS was in accordance with ISO 8879, not MIL-D-87269.

Our team decided to try using the MIL-D-87269 DTD with IADS to see if they were compatible. We made several changes to the 269 DTD in the areas of Frames, Files, and Warnings. We were able to use the DESCINFO, TASK, and TABLE tags provided. Implementing these changes to the DTD resulted in a partial 269 compliant DTD. The results of the Layer 0 Conformance Validation process for this modified DTD are documented in paragraph 3.7 below.

It should be noted here that the IADS system is freeware and all software and documentation for this system was obtained via the World Wide Web (WWW). Our team contacted the IADS development group to inform them of our project and our intentions with using a MIL-D-87269 DTD. They made themselves available for any questions we might have while working with their products.

Much time was spent working with the MIL-D-87269 DTD and IADS. Several hours were spent modifying the DTD to include the Frame, File, and Warning/Alert elements from the IADS 8879 DTD. Time also was spent on hotspot and external calls. It was determined that we must use the calls from IADS versus the linking elements in 87269.

In using the IADS system, our tagged textual data will be stored in ASCII text SGML tagged files. The graphics will be stored as BITMAPS with their associated Picture Definition Files (PIC), which stores the links for the graphic hotspots.

Recommended Personnel for this Process:  Conversion Group

Our Time:  39 hours

3.5  Program Conformance Registration

Now that all functional and contract requirements have been defined and the system software and DTD have been selected, QA registered and completed the IETM Qualification Screening and Profile Questionnaires. Using a World Wide Web (WWW) browser, QA entered the location address for the ICE Demonstration. The conformance validation test sets for levels 0 through 6 are maintained at location http://galaxy.mantech-wva.com/ice/qualify/int_page.html. When this location was entered into the browser, the IETM Conformance Escort (ICE) Demonstration frame was displayed.

To begin the registration process, QA would select the Register button to establish a profile record for the conversion project. Once this button has been selected, the User Registration for ICE frame was provided. QA would fill in the registration information:  Name, Company/Agency/Organization, Who will be represented (developer, user, or independent), Military Branch, End Item Defense Program, Phone number, E-Mail address, and Primary Authoring and Presentation Software being used (if available). QA is given the option to store this information for public viewing or place this information under built in security. When all information has been entered, QA selected the Register Me button.

Now that the conversion project has been registered, QA would be provided with the IETM Qualifications Screening and Selection screen. This screening process allows for streamlining the conformance testing while maintaining a modular testing approach. The hotspot to begin the Qualifications Screening Process would be selected.

This selection took QA to the Authoring Development Profile Questionnaire. The questions contained on this frame involve the authoring system, DBMS, and the requirements for final delivery. When these questions were answered, QA selected the Submit button.

The Authoring Development Test Set Questionnaire was presented next. This questionnaire concentrated on the DTD selected. The Submit button again was selected upon completion of the questions.

The next frame that was presented was the Presentation Operation Profile Questionnaire. Selected questions about the operation of the presentation system were asked. When completed, QA selected the Submit button to continue with the profile.

To further define the profile of the program, the Presentation Operation Test Set Questionnaire asked QA to select all of the non-text primitives that will be included. When the selections had been made, the Submit button was selected.

At this point, the program was registered and QA exited the ICE Demonstration program. QA will return to this program during each Conformance Layer Validation process. The below paragraphs will describe the steps taken during each layer validation process. Appendix D contains a copy of the final report produced through the ICE Demonstration program.

Recommended Personnel for this Process:  QA

Our Time:  10 minutes

3.6  Define Mapping Source to Target DTD

To successfully carry out a conversion project, the conversion team must determine an exact mapping for every unique item that will change when going from the source to the target. This mapping must be done at the very beginning. If the authoring and presentation systems were properly selected after carefully studying the results from the Preliminary Document Analysis (3.3) phase, then there should be no significant surprises during the mapping stage. Note that the mapping should not be confined to paper analysis. Every unique mapping instance should be identified and manually performed using the authoring system, and then its appearance should be verified using the presentation system. In any case, the mapping process must, at the very least, provide detailed guidelines on all the information constructs identified during the Preliminary Document Analysis process (3.3). This mapping process will reveal the ultimate complexity of the conversion project.

Once the MIL-D-87269 DTD was modified, parsed, and tested with the IADS authoring and viewing software, our team began the mapping process. Descinfo, Task/Steps, Warnings/Alerts, and Table elements were used from the modified 269 DTD to map the source document. The document was divided into chapters, then by either description information or troubleshooting/maintenance steps.

Once data was labeled to what type of information was contained within each chapter, paragraph, etc., the tag elements were hand written on a copy of the document. This information will be used when programming the auto tagging software (3.13.1).

Recommended Personnel for this Process:  Conversion Group

Our Time:  15 hours

3.7  Layer 0 Conformance Validation

This first layer (Data Structure Design) involves validating the developed and/or selected content specific layer for the IETM. Layer 0 follows the Content Data Model (CDM) approach from MIL-D-87269, and focuses on defining and/or developing a Content Specific Layer for the IETM from the architectural forms provided in the Generic Layer.

QA, using the same procedures to gain access to the ICE Demonstration, selected the Open button to gain access to the previously generated conversion project profile. The Open Previously Saved Qualification Profile frame was displayed and allowed QA to enter the Program Name supported by the IETM. This frame also allows a user to view other programs registered by selecting from a directory listing.

The IETM Conformance Test Series frame was presented next. This test series presented to QA were designed by the use of the questionnaire previously completed in paragraph 3.1.3 above. This frame explains the possible answers that will be allowed during the layer validation processes. The five possible answers are Pass, Partial, Fail, Did Not Consider (DNC), and Could Not Decide (CND). For layer 0, QA selected the MIL-D-87269 Test Suite hotspot.

The IETM Authoring Development Test Set Matrix was provided with selection buttons for the different layers that apply to the individual program. These buttons were determined by the answers provided during the registration process. At this time, QA was ready to perform the Layer 0 Conformance Validation process. QA selected the CSL DTD - Layer 0 button.

The Layer 0: Content Specific Layer DTD Test Set was developed using the requirements from MIL-D-87269. When QA completed this series of questions, the Submit button was selected and QA was provided the Layer 0: Content Specific Layer Test Set results. The results contained the answers to the Layer 0 questions and the percentages on partial, complete, and non-conformancy for the program. Our results are provided in Appendix D.

Recommended Personnel for this Process:  QA, Document Analyst

Our Time:  10 minutes

3.8  TM Source Data

Legacy technical manual data can exist in two categories: the data that exist only on paper and the data that exist in some electronic form. To get data into an electronic format, the paper data will require two levels of processing: text data capture and graphical data capture. Decisions made during the preliminary analysis and mapping phases may significantly affect the initial data capture and/or conversion process. Even when mapping to an exceedingly simple DTD, difficulties may be encountered because it is likely that not all the information constructs will be identified in the preliminary analysis phase (3.3).

The direction in which to proceed is determined here. If the TM is presented to the conversion service in an electronic form then the scan/OCR process is bypassed and the conversion team would go directly to the Tag and Link processes. In our demonstration, the TM was in paper form causing our conversion team to perform the scan/OCR processes.

Recommended Personnel for this Process:  None required.

Our Time:  Zero

3.9  Scan/Re-Enter

There are several options to get information that resides on paper into an electronic format, including using a large Conversion Service Bureau, Scan/Converting the TM data, or Manually Re-entering the TM data. Each of these options has its advantages and disadvantages. The decision on how to transfer the paper information into digital should be made during the Preliminary Document Analysis phase(3.3). The reasoning behind this decision will be based on such items as quality and quantity of the existing data, project budget and time, the availability of hardware/software and experienced personnel, and possible required formats needed for further processing.

Our decision to scan/convert and manually re-enter the technical manual data was based on the size of the document and the quality of the printed pages. At this point in the conversion process, our team began the job of scanning in the selected technical manual. It was decided that each page of the TM would be scanned in full and stored in its own file. Graphic cropping, and table break outs would be handed after the scanning process had been completed.

Our team used a HP ScanJet IIcx scanner with vendor supplied DeskScan II scanning software. We determined during the Preliminary Document Analysis process that scanning at 300 bpi was sufficient and we would store each scanned image as a bitmap file. The total number of pages scanned was 67 at a storage size of 68 meg.

Recommended Personnel for this Process:  Data Entry

Our Time:  1 hour

3.10  Convert

The process of converting the scanned raster data into a vector file can take on many forms. Optical Character Recognition (OCR) for text is the use of opto-electronic devices to obtain an electrical representation of printed characters on paper. These electrical representations are then manipulated in such a way as to generate computer images that can be analyzed and each image assigned a character. Symbol Recognition for graphics is similar to OCR where symbols from a database are used in the conversion of the raster graph to a vector format.

Prior to the OCR process, our QA team reviewed the scanned images using PaintBrush. During this review process, our QA team reviewed for poor images and areas that needed to be removed prior to the OCR process (i.e., West Virginia University Library stamp and change bars).

Upon QA approval, the character recognition process began using OmniPro. However, it was discovered that this software would not accept bitmap formatted files. Using PaintBrush, we converted all of the bitmap images to PCX formatted files. Once this had been completed, the OCR process began again.

The steps that were taken are as listed below:

1. Open PCX file,
2. Manually Zone text excluding graphics and tables,
3. Perform OCR,
4. Check and correct obvious character recognition errors, and
5. Save each new file as an ASCII text file.

For those pages that contained text with graphics or text with tables only, the text was selected for OCR. Tables where typed in manually using a text editor called NotePad. This was due to the poor results given by the OCR software when tables contained column division lines (which all of ours did).

When the above steps where completed for each of the scanned files, QA was notified to perform the Content Reconciliation validation process.

Recommended Personnel for this Process:  Data Entry

Our Time:  (Automated Conversion - 5.5 hours)

(Manual Conversion - 6 hours)

(Graphic touch up - 17.0 hours)

3.11  QA Content Reconciliation

Full content reconciliation of newly converted technical manual information can be a long, arduous, and expensive process. However, it must be performed at this point before continuing with the conversion project. This would include performing validation by either direct letter to letter match or if work packages were developed during the preliminary analysis process (3.3), the newly reconstructed digitized data are consistent with the original packages designed.

During this process, our QA team examined the ASCII text files. Character-by-character validation against the original paper document was performed. The software used for this validation was Microsoft Word. This software was used because of the ease for word search and replacement, and the spell checking tool provided.

The QA team also reviewed the graphic BITMAP files to ensure each drawing was clear and any text contained within the drawing was correct. Problem areas that were identified during this step were part numbers and drawing titles that were original in script form. These items were recreated using PaintBrush.

Recommended Personnel for this Process:  QA

Our Time:  8.5 hours

3.12  Layer 1 Conformance Validation

This layer validates the authoring system to ensure that it has the capability to encode information according to the hierarchical data structure, semantic rules, and attributes as defined in the content specific layer from Layer 0. The authoring system must also conform with both ISO 8879 (SGML), and applicable modules of ISO 10744 (HyTime), as specified by MIL-D-87269. Additionally, the authoring system must provide the capability to include the required content, style, and linkages and intelligence as specified by the IETM specification.

As in the Layer 0 Conformance Validation process, QA entered into the ICE Demonstration program and progressed to the IETM Conformance Test Series frame. After selecting the MIL-D-87269 hotspot, the IETM Authoring Development Test Set Matrix was again provided. At this point, QA selected the CSL Authoring - Layer 1 button.

The Layer 1: Content Specific Layer Authoring Test Set questionnaire was displayed for QA completion. This test set concentrates on the capabilities of the authoring system itself. When completed, the Submit button was selected. The Layer 1: Content Specific Layer Authoring Test Set results was displayed. Our results are provided in Appendix D.

Recommended Personnel for this Process:  QA, Document Analyst

Our Time:  10 minutes

3.13  Tag and Link

Conversion from an electronic file format to a tagged electronic file format may involve the steps of manually tagging the file, the use of COTS auto-tagging software and/or the use of in-house, customized, conversion software. The next step depends on how the files were originally processed and what the final ETM/IETM system will be.

In a conversion project, using an auto-tagger, writing conversion code, manually tagging the data by hand, or any combination of the three, will probably all be used. There is neither a defined order nor a defined limit on how many times these steps can be used. In fact, the COTS auto-tagging products on the market today do not provide the technology to do a complete conversion to any of the upper class constructs. Therefore, some sort of intervention either manually tagging and/or writing conversion code will be needed to complete the tagging process.

With all conversion projects, both automated and manual tagging will be required. The percentage of work for either will be dependent on the information within the document, how it was presented in the paper version, and how it will be presented in its electronic form. The goal of any conversion service group is to perform as much automated tagging as possible. This goal would shorten the conversion time and reduce possible typing errors. This reduction would ultimately reduce the cost of the project.

3.13.1  Automatic Tag and Link

Auto-tagger/conversion software are programs that look for clues in keywords, formatting, etc. of a given document. With this in mind, the customization of the auto-tagger/conversion software would be the next step.

Customization of an auto-tagger or conversion software means two different things. Customizing conversion software means writing scripts to identify clues in the text, determine the mapping relationships, and replace the clues, if necessary, with the tags in the new corresponding DTD. The auto-tagger would need the clues identified and the mapping relationships stated for customization. The difference is that the auto-tagger would be more generic, for everyone’s needs, on its ability to identify and convert, but the conversion software could be more specific -- for the individual project needs. In other words, the algorithms between the auto-tagger and conversion software might be the same, but because the service is able to edit the conversion software, more tagging could be accomplished to meet the project needs.

Our team selected Avalanche FastTag for the automatic tagging of our document. Avalanche provided our team with a complete copy at no cost for a 90-day license period. Time was spent on familiarization of the software and the programming requirements. Several test runs using samples from our document were performed to understand the requirements and techniques needed to fully utilize this software.

Our team also utilized C coding scripts developed to further enhance the automated tagging process. The C scripts were used primarily to insert the hotspot/action tags within the text for appendices and figure callouts.

Once we had determined what was needed in the FastTag scripts, the actual programming began. This involved using the mapping layout defined above. The proper tagging elements were placed in the scripts, and the process of automatically tagging the document files began. Appendix E contains the FastTag Inspect and Louise files, and the C coding scripts used for our automated conversion effort.

Recommended Personnel for this Process:  Document Analyst, Programmers, Technical Writers, Data Entry

Our Time:  (Research - 48 hours)

(Actual Automated Tagging - 2 hours)

3.13.2  Manual Tag and Link

Manual tagging can occur throughout the tagging process, before and/or after either auto-tagging software or in-house conversion software. Its use depends on the pre-processing needed for the software and the post-processing needed for the final product. Manual tagging can be used exclusively for converting to a lower class ETM or not at all.

The manual tagging for our chosen document was performed on tables, in areas of frame division, and graphic hotspots and links. Manual tagging was also performed for trouble shooting links. The SGML tags for the tables and frame divisions were inserted into the files manually using the text editor NotePad after the automated tagging was performed. The graphic hotspots and links were accomplished using the IADS Viewimage Graphic editor.

Recommended Personnel for this Process:  Document Analyst, Technical Writers, Data Entry

Our Time:  40 hours

3.14  Layer 2 Conformance Validation

This layer validates the requirements that apply to the IETMs and/or the interchange format of the IETM database. Other requirements at this layer might apply to the processes for reading IETM data, and/or extracting IETMs and/or View Packages from the IETM database.

As in the Layer 0 and Layer 1 Conformance Validation process, QA entered into the ICE Demonstration program and progressed to the IETM Conformance Test Series frame. After selecting the MIL-D-87269 hotspot, the IETM Authoring Development Test Set Matrix was again provided. At this point, QA selected the Instance Sto./Int. - Layer 2 button.

The Layer 2: Instance Storage/Interchange Test Set frame was displayed. These questions are testing the delivered output instance for the program. When completed, the Submit button was selected and the Layer 2: Instance Storage/Interchange Test Set results were displayed. Appendix D will provide the actual answers and results to the Layer 2 test set.

Recommended Personnel for this Process:  QA, Document Analyst

Our Time:  10 minutes

3.15  View Package Development

The development of a view package in-house would be considered a full software development project in itself. The operation of the view package depends on the functional capabilities required for the specific conversion project. If this development process were required, project time and cost would be greatly increased.

Our conversion project demonstration requires us to follow the class 2/class 3 constructs. Keeping this in mind when we selected the authoring/viewing software, IADS provides a complete viewing package that follows the MIL-M-87268 requirements. Our team was not required to develop any view package software for our ETM system. However, paragraph 4.3 contains a list of enhancements for the selected view package that would increase the usability and provide greater viewing capabilities.

Recommended Personnel for this Process:  Customer, Conversion Group

Our Time:  None required

3.16  Browser Testing and System QA

The Validation & Verification & Acceptance processes are tasks that would normally be shared by both the QA team and the customer. A consistent methodology, applicable for all Types or Classes, for conversion service validation, customer verification, and customer acceptance testing of converted TM information must exist. The conversion methodologies are based on the premise that the (to be converted) source data, whether on paper or in electronic form, were previously validated by the originator and both verified and accepted by the Customer.

Validation is the conversion service QA process in which an ETM/IETM or the data that constitute that ETM/IETM are compared in detail against the system supported by the ETM/IETM, or against other approved source data, to assure that the presented ETM/IETM data are technically accurate in all respects and conform to all requirements of the contract. Validation is the most important of the conversion service’s QA actions. This team would follow the defined set of procedures described in the Test Plan developed for the specific conversion project. Validation involves tests of the ETM/IETM information against the associated hardware by actual performance of the procedures by conversion service personnel using a Customer furnished Electronic Display Device (EDD) and other Customer approved support equipment in accordance with the validation plan and other contract requirements.

Verification and Acceptance testing would be performed by the customer using qualified personnel with a prescribed skill level, from the operating command or facility assigned to operate and maintain the system to which the ETM/IETM applies. These tests would ensure the suitability of the ETM/IETM for the intended maintenance environment, its usability by its intended users, and its capability with other customer systems.

When our conversion team was satisfied with the new ETM system, we passed the system to our QA department for final validation testing. A user id was established (gijoe) as the login for these tests. When QA selected the viewing package software and entered the user id, they were automatically placed at the Table of Contents for the technical manual and proceeded through the document. All hotspots were verified to ensure they were properly linked to their associated file, all custom buttons were tested to verify that they placed the user in the proper location, and all returns to the originating frame were validated. During these tests' appearances, ease of use, and display consistency where checked.

During this validation process, all discrepancies were documented and returned to the conversion team for correction. When all corrections were made, the system was again passed back to QA for re-testing. This stage was repeated until all problems were solved and QA was satisfied with the final product. At this point, all data files, style sheets, graphics with link files, and all software and conversion scripts where placed with CM for proper logging and storing in the Customer Production Baseline (PRBL_ARM) main directory.

Recommended Personnel for this Process:  QA, CM, and Document Analyst

Our Time:  7 hours

3.17  Layer 3 Conformance Validation

The two distinct items under test in this layer are the Presentation System and the IETM Instance. The Presentation Layer isolates on both display and operating related requirements to specifically test for the correct interpretation, formatting, and display of Display Elements, Alert Elements, Graphic Elements, Process Elements, and technical Information (content, display, organization, and style) requirements. The interdependent relationship between the presentation system and the IETM instance is the process of interpreting the IETM.

As in the prior conformance validation process steps, QA accessed the WWW to gain entrance to the IETM Conformance Escort (ICE) Demonstration system and progress to the IETM Conformance Test Series frame. At this point, QA selected the MIL-M-87268 Test Suite option. The system placed QA at the IETM Conformance Test Set Matrix frame. This allowed QA to complete the Layer 3 through 6 conformance validation test sets.

For layer 3 validation, QA selected the Content Test Sets button at the layer 3 Presentation Operation, Authoring System, Technical Information cell. When selected, the Layer 3: Content Test Sets become available for QA selection. These test sets have been designed using the information provided during the Program Conformance Registration process above.

At this time, QA progressed through the General Content (General/Primitives) Test Sets, which included test sets for General Content, General Style, Graphics, Alerts, Procedural Information, Troubleshooting Information, Parts Information, and Descriptive Information. After each test set, QA was provided a report documenting the results of the individual test.

When the General Content Test Sets were completed, QA returned to the Test Set Matrix frame so that the Display Format/Functionality button could be selected. QA progressed through the Text, Graphics, GUI, Alerts, and Elements test sets. Once again, QA was provided with a report documenting the results after each individual test.

Upon completion of all layer 3 validation test sets, QA was ready to progress to the layer 4 Graphical User Interface and Technical Information Interaction Test Sets. The results of the layer 3 test sets are provided in Appendix D.

Recommended Personnel for this Process:  QA, Document Analyst

Our Time:  1 hour

3.18  Layer 4 Conformance Validation

The Human-Computer Interface layer, Layer 4, validates requirements that pertain to the Common User Interface and Interaction Functions. Again, many requirements in this layer will require testing both the presentation system and the IETM instance simultaneously. Common User Interface requirements include user accessible services such as cursor movement, selection functions, menu functions, navigational functions, dialog control functions, audio control functions, etc. Interaction Functions pertain to those aspects of operation that involve a two-way interchange of information between the human and the computer.

The layer 4 test sets can be accessed immediately following the layer 3 conformance validation. After reviewing the final results from the layer 3 test sets, QA returned to the IETM Presentation Operation Test Set Matrix. The buttons for layer 4 were available for selection. Our QA selected the Graphical User Interface Test Set button first.

This selection allowed QA to complete the HCI Common GUI and HCI GUI Menu test sets. Again, as in the layer 3 test sets, a report displaying the results of each test set was displayed immediately following the completion of each individual test.

When QA progressed through the GUI test set, the Technical Information Interaction Test Set button was selected. This selection allowed QA to complete the Troubleshooting Interaction, Graphic Interaction, and Tables Interaction test sets. After reviewing the results, QA returned to the Presentation Operation Test Set Matrix frame so that layer 5 conformance validation could be completed. The results of the layer 4 test sets are provided in Appendix D.

Recommended Personnel for this Process:  QA, Document Analyst

Our Time:  1 hour

3.19  Layer 5 Conformance Validation

The Test Sets at this layer pertain to hyperlinking requirements and conditional branching requirements. Because requirements in this layer apply to two distinct areas, individual tests will be run for each hyperlinking and conditional branching. Testing on the links will validate the requirements that allow the user to branch from the immediate technical information to other related information. The test performed on the conditional branching requirements will validate that the presentation system evaluates the pre-conditions correctly such that the right node or frame of the IETM is accessed.

While QA was located in the Presentation Operation Test Set Matrix frame, the Layer 5 Logic Flow Linking button was selected. This button allowed QA to perform the Linking Test Set. After all selections had been made and submitted, the final test set report was reviewed.

This report contains the answers to all of the layers’ test sets and the results of compliancy for the overall system. This report is provided in Appendix D.

Recommended Personnel for this Process:  QA, Document Analyst

Our Time:  30 minutes

3.20  Layer 6 Conformance Validation

The layer 6 conformance validation test sets pertain to interfacing (calling, spawning, and/or linking) external software processes such as LSAR, diagnostics, etc. All external processes (nodes, etc.) referenced must exist, be accessible, and be able to be displayed. In the case of external data type (and external file entity), the SGML Notation definitions must be enabled. These SGML notations support external processes with external non-SGML data types. Processing of the external file entities is handled at presentation-time by the presentation system.

Our ETM system does not contain these external software links. For this reason, there were no layer 6 test sets that apply, and QA exited the ICE Demonstration system.

Recommended Personnel for this Process:  QA, Document Analyst

Our Time:  none

3.21  Delivery to Customer

The list of deliverables will vary depending on the Type or Class of ETM/IETM being acquired and on the customer requirements. The customer will compile the list of desired deliverables for delivery by the conversion service. A schedule for these deliverables during the conversion process and/or upon completion of the conversion effort and acceptance testing would be developed and agreed to by both parties prior to the start of the project. This list will be included in the conversion project contract and mutually agreed to by both the customer and the conversion service. The media used for delivering the products will be in accordance with the requirements stated in the contract.

According to our ETM/IETM Conversion Project Costing Matrix (Appendix A), our conversion team would be required to deliver the newly generated ETM on a 3 1/2" 2.88 MB Cartridge Tape. The following items to be included on these tapes were defined in paragraph 3.1.2  Additional Conversion Project Requirements:

1. Converted text (.TXT) and graphics (.BMP) data files;
2. Parsed SGML Tagged (.INI) files;
3. Picture Definition (.PIC) files;
4. Modified MIL-D-87269 DTD (.DTD);
5. Authoring/Viewing Software Package with all licensing agreements required; and
6. Automated Conversion scripts and code.

Once these tapes have been made, our QA team would verify that the contents where valid and complete. As part of the final QA tasking, QA would restore these tapes to an equivalent user system and run a final verification test on the software and data files to ensure that the contents performed properly. The main objective of this final validation is to ensure that the conversion service has provided, for support of the equipment involved, accurate and adequate ETMs/IETMs and/or ETM/IETM data. Once satisfied, the tapes would be delivered to the customer. Along with the tapes, setup, loading, and user instructions would be provided to aid the customer with their new ETM system.

Recommended Personnel for this Process:  QA, and CM

Our Time:  none

4.0  Conclusions

      

This section discusses the findings from our Concept of Operation demonstration along with the problems that were encountered and their solutions. We have also included a list of software enhancements for the IADS system.

4.1  Demonstration Results

As stated in paragraph 1.1 above, the purpose of this demonstration was to show the defined concept of operation for ETM/IETM conversion. Our demonstration primarily focused on the general conversion process as defined in Section 3.0 of the IETM Conversion Service Concept of Operation document.

As described above in Section 3.0 Concept of Operation Demonstration, our team followed the processes and steps in the order of design. We found no alterations were required in the sequence of those processes.

However, one additional process was added to the general conversion process. This new process has been named Program Conformance Registration. This new process was placed between the software/DTD selection and the mapping processes. The Program Conformance Registration allows the QA team to begin preparing for the level 0 through 6 validation processes by registering the conversion program using the WWW. By registering the program and completing the IETM Qualification Screening and Profile Questionnaires, the system sets up the process for streamlining the conformance testing while maintaining a modular testing approach. This also allows QA to view other programs that have registered and performed validation on their ETM/IETM systems. This process is fully described in paragraph 3.5 above.

4.2  Problems and Solutions

The sections below discuss two areas that impacted our teams' effort and time in the conversion of the selected technical manual. They are the conversion of tables and graphics, and lack of familiarity with the software products.

4.2.1  Table and Graphic Conversion

One problem that has always existed for legacy conversion is the automated conversion of tables and graphics. Quality and style of these items play an important role in the automated conversion effort.

The quality will have an impact on the conversion process by way of time, skills, and software required to convert the data into a suitable format for ETM/IETM development. The end resulting factor for the quality of the initial data will aid in the determination of the final conversion schedule and cost. Note that the poorer the quality, the more time is required for conversion, and thus the higher the cost.

The style has no impact on the initial scan, but when text is OCRed, special characters, fonts (i.e., scriptive, bold, or small size), and bounders for tables caused many problems. These problems may require more time for conversion and thus increase the final cost of the conversion project.

In our effort to convert the selected technical manual we found that the tables and graphics were at medium quality. However, after scanning and OCRing, alterations were required. Tables had to retyped by hand due to the bounders and different size fonts within them. The graphics required retyping titles and part numbers because of scripting and font sizes used in the drawings. These additional tasks required more time then the actual tagging process.

A couple of software vendors are attempting to create table converting routines and graphic recognition applications that would lessen the time and effort currently required to generate the quality electronic versions.

4.2.2  Software Familiarization

As stated in the Concept of Operations document, to be successful, a business must employ highly qualified and motivated personnel. Besides the project manager who must maintain an in-depth knowledge in the ETM/IETM environment, several key areas of support must be filled with highly skilled personnel. All personnel assigned to a conversion project should, at a minimum, maintain a basic knowledge in ETM/IETM design and requirements. They must also be familiar with the ETM/IETM software package and automated conversion tools.

Our team contained the knowledge of ETM/IETM design and standards required. Where we were lacking was the familiarity with the selected ETM software package and automated conversion tools used during the conversion effort. Several man hours were spent gaining the knowledge required to efficiently use the ETM software and to fully understand the requirements and techniques needed to fully utilize the auto-tagging software. In a real conversion business, experienced programmers would provide the knowledge required for the conversion software. Some time may be required for the ETM/IETM software depending whether it had been used in the shop previously.

4.3  Suggestions for Software Enhancement

IADS is an Authoring/Viewing software system that is both developer and user friendly and can be utilized for almost all class2/class 3 defined electronic technical manuals. During our demonstration of the conversion processes and while working with the complete IADS system, we compiled a list of possible enhancements that would provide the ETM developer more functional capabilities at their disposal. They are as follows:

1. Allowing the ETM developer the option of split windows. This would provide the option of displaying multiple bits of information side by side versus overlaying important data. Examples of this are repair step with parts list, repair step with graphic, and table of contents with the selected section.

 

2. Provide the option to include the graphics within the viewing window versus overlaying the calling data with the graphics viewer. This will allow the user to read the associated information with the graphic.

 

3. Create a way to self generate a style sheet according to the DTD selected for use.

 

4. From the DTD the user selects, have IADS query the user to select elements, contained in the DTD, such that they replace mandatory elements (‘FILE’ and ‘FRAME’ elements, to name a couple) that IADS now requires. This would allow for more DTDs, such as MIL-D-87269, to be used without having to alter them to fit the authoring system.

Appendix A:  ETM/IETM CONVERSION PROJECT COSTING MATRIX

      

About the Conversion Project

About the Conversion Effort

Appendix B:  ETM/IETM CONVERSION PROJECT PROJECTED PRICING CHART

      

Appendix C:  ETM/IETM CONVERSION PROJECT STEP SUMMARY TABLE

      

Note 1:  Time has been spent working with the MIL-D-87269 DTD and IADS. To this point we have had to modify the DTD to include the Frame, File, and Warning/Alert elements from the IADS 8879 DTD. Time was spent on hotspot and external calls. It was determined that we must use the calls from IADS vs. the linking element in 269. We were able to use the table structure from 269, so that remained the same.

Note 2:  The character recognition process began using OmniPro. However, it was discovered that this software would not accept bitmap formatted files. Using PaintBrush, we converted all of the bitmap images to PCX formatted files.

Appendix D:  IETM CONFORMANCE ESCORT (ICE) DEMONSTRATION REPORT

      

Name = L. King

Company = Scan R Us

TestParty = 1st Party Tester (Developer of IETM)

Service = Army

Program = an_pvs5

Phone = 301-871-2769

E-Mail =

Authoring = IADS

Presentation = IADS

Secure = Off

SGML_Output = Yes

DBMS = No

Authoring_System = Yes

O-Level_DTD = Used_in_Instance

Conditional_Branching = No

External_Interface = No

Tables = Yes

Graphics = Yes

Audio = No

LSA = No

Software = No

There are 9 Requirement(s) for Test Set

There are 13 Requirement(s) for Test Set

There are 6 Requirement(s) for Test Set

There are 1 Requirement(s) for Test Set

There are 14 Requirement(s) for Test Set

There are 1 Requirement(s) for Test Set

There are 21 Requirement(s) for Test Set

There are 12 Requirement(s) for Test Set

There are 6 Requirement(s) for Test Set

There are 13 Requirement(s) for Test Set

There are 2 Requirement(s) for Test Set

There are 22 Requirement(s) for Test Set

There are 2 Requirement(s) for Test Set

There are 6 Requirement(s) for Test Set

There are 1 Requirement(s) for Test Set

There are 7 Requirement(s) for Test Set

There are 3 Requirement(s) for Test Set

There are 2 Requirement(s) for Test Set

There are 1 Requirement(s) for Test Set

There are 1 Requirement(s) for Test Set

There are 14 Requirement(s) for Test Set

There are 3 Requirement(s) for Test Set

There are 1 Requirement(s) for Test Set