Sensible Systems, Inc -- A leader in Automated Support for Responsible Occupational Analysis
For Historical Interest ONLY!
For current information,  please see: <http://www.icodap.org>

Table of Historical Dates

OASurv - the Survey Administration Engine

OASurv was developed by Metrica, Inc. to support automated survey requirements for US government data collection projects. Ongoing maintenance and enhancement has moved to the Institute for Job and Occupational Analysis (IJOA) to meet ever changing government needs in new application areas.

OASurv is a program (OASURV.EXE) which reads a script file (a standard MS-DOS Text File), formats questions and collects, validates, and records data from survey respondents. OASurv is very much like an actor playing a part -- what you see will depend on the contents of the script. In today's terminology, "OASurv" is called a survey engine. This analogy equates the program (i.e., "OASurv") with an engine and equates flat text file ("your script") with the gasoline. Hence, without an human author to create the script, OASurv isn't going anywhere.    You will also hear the term "AUTHOR" to refer to a windows-based program which helps create the OASurv script file as well as prepare MASTER diskettes and aggregate data from disks after survey administration.  The "AUTHOR" program may be thought of as the automobile factory in which prototypes are designed and assembly-line copies created to meet demand.

OASurv History

The original funding for OASurv's development was partially drawn from AF Contract F33615-91-D-0010, DO 0013 - MPT Functional Relationships. This project required a fairly standard set of background items as well as special-purpose modules to achieve the goals of this study. In each of 21 different career areas, this project showed a pre-screened subset of approximately 60 tasks to each of 200 job incumbents and allowed him or her to rate "familiarity" on a nine-point scale. For those tasks rated 7, 8, or 9 (highly familiar) the job incumbent provided direct time estimates for targeted tasks under various conditions. When the job incumbent finished with the survey disk, the same disk was turned over to the incumbent's supervisor for ratings of incumbent proficiency and training investment.

While the data collected in this project was not the "relative time spent" ratings usually collected for use in the Comprehensive Occupational Data Analysis Programs (CODAP) system, OASurv was designed to be flexible enough to capture a wide range of data types. This was easy to accomplish since the people who designed OASurv have years of experience and "lessons learned" from several sources. The first script-based survey engine goes back to graduate school investigations in 1980. This work studied disk-based surveys from an educational-psychology perspective followed by operationalization of those techniques in the development of the "driver" programs used for data collection and psychological testing in the Learning Abilities Measurement Program (Project LAMP) in 1981. By August 1982, the same design specifications were used to develop the Computer Assisted Inventory Delivery System (CAIDS) used with an occupational data collection project across 12 job families for the San Antonio utility.

With the grow emergence of the IBM PC, previous versions of survey engines were shelved and Sensible Systems' atSURVEY program was developed. Final debugging was accomplished in the hotel room at the MTA conference in 1990. This program allowed multi-track, multi-list data collection. A single project collected over 20,000 disks across the United States, the United Kingdom, Germany, and Belgium and supported six possible tracks per disk.

By 1991, the Air Force Occupational Analysis Program began to consider automated data collection. Because the new media presented new possibilities for data collection methodologies, research programs were initiated to evaluate possible alternatives. This initiative resulted in a package of approximately 20 programs (the Computer Administered Survey (CAS) System). The development of these programs drew on both the script-based designed described above and a series of "data entry" programs previously developed in the military by the programmer. Data collection was initially envisioned as a mailout system to eight career fields (three treatments each.) Any one of the 24 experimental treatments could fit on a single 5 1/4" double density floppy. The need for controlled conditions during this sensitive measure phase, however, altered plans for data collection. Data was collected on the 30+ computers in the Project LAMP computer lab. As each Project LAMP computer had to be able to administer the proper treatment whenever a subject "logged-in," all treatments had to be loaded to each machine. The entire set of research programs required three 5 1/4" floppies to install them on a Project LAMP computer hard disk.

As the CAS methodology research was underway, the question of the logistical hurdles of using mailout disks arose again. Under the auspices of the Institute for Job and Occupational Analysis (IJOA), a feasibility study was undertaken in 1993. As none of the CAS programs closely matched standard paper-and-pencil (optical scan sheet) methods used by the Occupational Measurement Squadron (OMS), alternate programs were developed for this feasibility study. These few programs (background data collection, task list programs for relative time spent, task learning difficulty, and training emphasis). These programs were called the Computer Administered Occupational Surveys (CAOS) to reflect their closer ties to the OA operational community rather than the research community of CAS.

The project from which OASurv sprang began in mid-1995. Initial review showed at least eight "unique" data collection programs were required. A "unique" data collection is one which can ask and record only a specific kind of question or data set. This is required if the program must cross-compare data or collect data of a very specific format which must be validated and corrected. The opposite of a "unique" data collection program, then, is a "generic", "general", or "robust" data collection program. To meet deadlines, the most appropriate model from the CAS systems were selected as starting platforms. As the first three reached completion, it became clear that a single engine would be possible. As the fourth and fifth "unique" engines were completed, the new unified "OASurv" began to take shape and finally pre-empt all subsequent programming on "unique" engines.

OASurv Support Programs

OASurv is, however, only the lead product in a series of programs designed to support a wide range of operational data collection for occupational analysis projects.

OAVirus - Virus Checking

This multi-person use of the survey diskette mandated the development of non-proprietary VIRUS checking procedure. This procedure is called OAVirus and can be automatically added after a MASTER SURVEY diskette has been produced.

OASys - Inventory of Computer System Hardware/Software

This project also wanted to capture system information to determine if the job incumbent and supervisor data were collected on the same physical machine. There was some concern that job incumbents would simply do the supervisor's survey rather than actually turn over the survey disk. To this end, the Volume Serial Number is copied from Drive C as well as a complete equipment inventory. This system inventory capture is called OASys. It is strongly recommended that this program be used in all automated surveys so a centralized data base of the Air Force computer inventory can be developed.

LOGTIME - An event time stamp program

To the same end of determining if an incumbent is completing the supervisor's survey, an event-log (LOGTIME) was developed and incorporated into the batch runs which control this survey (SURVEY.BAT, \INCUMB\SCRIPT.BAT, and \SUPV\SCRIPT.BAT).

SHOWWHO - A program to control access to diskette.

Both the job incumbent and supervisor were allowed to start, stop, and restart the survey to fit their schedule. Once a person records data on the disk the Privacy Act kicks in and each restart requires a re-enter of the Social Security Account Number.

OVERVIEW OF FEATURES

To use OASurv, you need a diskette with a "batch" file (SURVEY.BAT) to sequence the required computer issues like Virus Checking, Event Logging, and actually starting the OASurv program.

OASurv can 1) Display Instructions; 2) Ask Background Questions; 3) Collect List-based information (such as Base List, Equipment List, Task List, etc.); 4) Accept Open-Ended Input; and 5) Conditionally Branch to or around items. 

Display Instructions

Instructions are classified into in three types.

Type One: Standard Instructions (intermixed in SCRIPT.TXT)

Type One Instructions are those instructions in which you fill the entire screen with whatever you want the survey respondent to read. This includes such things as the survey cover page with AFPT, the Privacy Act Statement, the Eligibility Statement, etc. These instructions may appear at the beginning, middle, or end of the inventory. The survey author may enter the text for these items in the SCRIPT.TXT file at the time he or she is drafting the survey and specifying the background questions and/or recording options to be used in rating assignments.

Type Two: Pop-Up Instructions/Help (OASURV.HLP)

Type Two Instructions are those instructions that you might want to give BEFORE entering a rating exercise AND allow the rater to ask to see them again DURING the rating assignment. During the rating assignment the Type Two Instructions may be "pop-ed up" by pressing the [F1] (HELP) key. The organization using OASurv may wish to standardize the HELP for routine applications. Text for these instructions is stored in the OASurv.HLP text file.

Type Three: Form-Flash Instructions (OASURV.DFL)

Type Three Instructions are those that you want to appear at the top of the screen at all times WITHIN a rating assignment (like the definition of the "Relative Time Spent" scale). As with Type Two instructions, the organization using OASurv may wish to standardize the SCALE FORM-Flash for routine applications. For this reason, the text for these form-flash instruction is stored in the OASurv.DFL text file.

Ask Background Questions

Background questions are classified into three types.

Type One: "Fill in the Blank..." (@BACKITEM)

Type One Background questions are "Fill in the Blank" for questions like NAME, SSAN, Job Title, etc. You restrict the type of characters or data you will accept for this Type One item. Data types include: Numeric, Alphabetic, Printable Type, Date (YYMMDD), or Duration (YYMM).

Customized formats can be specified using the "M" for "mask" that allows the survey author to specify each position and the required length of a response. For example, one might ask for Social Security Account Number (SSAN) and specify a length of "9" with a data type of "N" to ensure all numeric characters. If a person mistyped his or her SSAN and left out a digit (i.e., only typed 8 numbers) - that would be acceptable because each digit is numeric. To ensure proper format, a survey author may add the "mask" of "M:nnnnnnnnn" which not only requires each character to be numeric, it will only accept a response if it has NINE numbers.

Type Two: "Which choice best describes..." (@BACKITEM)

Type Two Background question you select "the best" response from a list of choices which fits on a single computer screen. This category includes items like Job Satisfaction and Gender. Again, inputs may be audited either as to type (numeric, etc) or as to validity within an enumerated set (like <MF> for Male/Female or <123456789> to exclude 0)

Type Three: "Pick One from the following list..." (@PICKONE)

Like Type Two, the Type Three Background questions are also a "Choose ONLY ONE" response, but for those questions in which the list is too long for a single screen. Type Three supports a "code" value associated with each choice (like Base code) so only the code for a single item is stored. If no codes are associated with a list, then the item number within the list is stored. Although equipment check lists are considered "background" questions in CODAP, the "Check all that apply" type question is collected by OASurv in the "List-Based" questions which follow in the next section.

Collect List-Based Information

To OASurv, all lists are treated the same, so you can apply what you read here to Equipment Lists, Knowledge Lists, Courses Taken Lists, etc. Only one list can be selected as the "Task List" for CODAP -- all others will be coded as a SERIES of background items.

Each list file produced by a survey author (like TASKS.TXT) or extracted and converted from TIARA (like BASES.TXT) must be processed by the "MAKEFAST" program to produce a rapid-access version of those inputs. This program will take a file like "TASKS.TXT" and output a file called "TASKS.FAS". Only the "<name>.FAS" files should be copied to the OASurv Survey Disk. If you use the IJOA AUTHOR system or the MAKEDISK batch procedure, this issue will be handled automatically.

Type One: Check IF Done or YesNo Items (@YESNO)

Type One Inventory questions are like the task list "Check IF Done" and equipment usage (Use/Don't Use) check lists - ones in which you "Check all that apply." A "Yes/No" (or "no response=*") type response is stored for every item in the list.

Type Two: Rate each Item (@RATEMANY)

Type Two Inventory questions are similar to Type One, except you rate some value on a scale like "Relative Time Spent" or "Frequency of Use." A rating response is stored for every item in the list. Note: If you ask a respondent to do a "Check all that apply pass," you can instruct the Rating Pass to use ONLY those items checked. This is the normal process for Job Incumbents. When using TE and TD ratings, the "Check" pass is not used and the "Rating" pass will automatically solicit a response for every item unless you specifically request a YESNO (i.e., Check first) pass.

Accept Open-Ended Input for Comments/OTHER (@TEXTED)

If an OASurv Survey Author wants to solicit a Text input in case of an "OTHER" (or any other selected response), a mini-Text Editor is available to accept input. At least one line of prompt for the editor screen is required. If extensive instructions (or a FORM) is desired, the editor may be "pre-set" to desired contents.

Conditional Branching (@BRANCH)

OASurv supports assigning Externally Recognized Names to items in the survey. Any item with an External ID can be 1) queried by other items to check responses OR 2) jumped to from somewhere else in the survey. The Condition Transfer command basically asks if the Externally Named item had a response equal to a specified value. If the specified value is found at the Externally Named location, the transfer takes place to the Externally Recognized Name at the end of the Transfer statement.

-------- End of OASurv Write-up ---------

Table 1:

Historical Development of Automated Occupational Surveys

Return to Top of Page

Return to Research Page

Copyright © 1997-2001  Sensible Systems, Inc.