Abstract:
The invention provides a centralized administrative system and method of administering standardized tests to a plurality of examinees. The administrative system according to the present invention is implemented on a central administration workstation and at least one testing workstation located in different rooms at a test center. The administrative system software which provides substantially administrative functions is executed from the central administration workstation. The administrative system software which provides functions carried out in connection with a testing session are executed from the testing workstations.

Description:
This is a continuation of application Ser. No. 08/129,473, filed Sep. 30, 1993, now abandoned. 
    
    
     BACKGROUND 
     The recent availability of a computer based testing system such as that described in co-pending application no. 08/082,058 has substantially automated the entire process of standardized testing. A typical standardized testing arrangement using a computer based testing system is shown in FIG. 1. A central processing facility 1 provides the software development to support the computer based testing system and post processing activities. For instance, one test program such as a GRE (General Record Examination) may be developed, produced and packaged at the central processing facility 1. The computer based test is then transferred to one or more test centers 2. Each test center 2 has at least one computer workstation 3 on which the computer based test can be delivered to an examinee. 
     Examinees typically register to take a particular computer based test at which time the examinee schedules an appointment to take that test at a specified test center 2. When the examinee arrives at a test center 2 to take the test according to his or her appointment, a test administrator typically confirms the examinee&#39;s appointment and initiates the test. After an examinee has taken the test the examinee responses and other information recorded during the testing session are transferred to the central processing facility 1 for post processing, i.e., for statistical and analytical studies used in the development of new tests. 
     In contrast to classroom tests which are usually given to a small number of students and are scored by one person familiar with the activities of the students and conditions in the classroom during a testing session, standardized tests may be given to thousands of examinees at literally hundreds of test centers on different days and at different times. Thus, in a standardized testing environment it is crucial to be able to track conditions at a test center, such as problems with the hardware or software or power outages which may effect examinees&#39; testing sessions. Additionally, when a test is not given at the same time and same place for all or most examinees it is necessary to provide additional security measures for maintaining the security and integrity of the computer based tests and any related test data including examinee responses. Therefore, the computer based testing system provides an administrative system to implement these functions. 
     Unfortunately, the administrative system and the test delivery system (which is the software that delivers the computer based test to the examinee and records examinee responses) reside together on a computer workstation 3 at a test center 2 shown in FIG. 1. Therefore, an administrator must perform many the administrative tasks on the computer workstation 3 prohibiting the use of the computer workstation 3 for testing. Moreover, most test centers 2 will provide a single testing room wherein the computer workstation 3 will be set up for computer based testing since it is usually logistically impractical to provide a private room for each computer workstation 3. Therefore, when each examinee arrives to take his or her scheduled test, the administrator must necessarily bring the examinee into the testing room where other examinees may be currently taking a computer based test, to check-in the examinee when he or she arrives, check the examinee&#39;s identification, capture the examinee&#39;s image if required, and initiate the test according to the examinee&#39;s appointment data. Such activities may be disruptive to other examinees taking a test particularly where the test includes timing constraints often required by standardized tests. 
     Furthermore, unexpected events occur at the testing center to which the administrator must quickly respond. For example, an examinee may call to make an appointment while the administrator is attending to a different administrative function. The administrator must be able to respond to the phone call without losing the work in progress. Computer based testing systems currently do not permit test administrators to quickly switch from one function to another in order to respond to events as they occur. 
     Furthermore, computer based testing systems currently do not permit different test developers to produce tests deliverable by the administrative systems provided as part of computer based testing system. For instance, Educational Testing Service develops, produces, and packages computer based GREs (Graduate Requirement Examination). An independent testing service, such as Sylvam Kee Systems (SKS), provides the scheduling and registration, the test centers, and the administrators at the test centers. The computer based testing system includes a test production system, a test delivery system, and a test administration system. Examples of such system are described in co-pending application Ser. No. 08/082,038 filed on Jun. 22, 1993 which is incorporated by reference herein. Testing services such as SKS, however, are currently unable to interface computer based tests produced by different entities without each entity providing a separate administrative system to perform the administrative functions discussed above. 
     Furthermore, computer based testing systems do not contain a feature that allows new tests to be added, old tests deleted, tests to be enabled or disabled, or ancillary system functions to be added, enabled or disabled easily, particularly if the administrative system is in operation. 
     Therefore, there is a need to provide a versatile and flexible administrative system on a workstation dedicated to administrative functions. 
     SUMMARY OF THE INVENTION 
     The present invention fulfills this need by providing a centralized administrative system and method for administering computer based tests. The system according to the present invention is configured in software to provide a start-up procedure for initializing a central administration workstation and to display a main menu on the central administration workstation display. The system also provides a start of day subsystem to receive an update of the scheduled tests in the form of appointment data and to start-up at least one testing workstation on which the scheduled tests will be delivered to an examinee. A start test subsystem comprising start service and general station administration modules generate a job info file and a job data file which are used to invoke and execute the computer based test are also provided. A check-in subsystem is utilized by an administrator to verify each examinee&#39;s identity and appointment data and to provide the administrative system with an indication that the examinee has arrived and is ready to take the scheduled computer based test. A close of day subsystem is also provided to transfer any records generated while the administrative system is operating to an independent data center. A communications manager is preferably provided to transmit and receive data between the test centers and the independent data centers. 
     The centralized administrative system according to the present invention is preferably implemented at a test center at which one central administration workstation, one file server and at least one testing workstation are provided. The central administration workstation is preferably configured to execute an administrative kernel, a start of day procedure, a start service procedure and a central station administration procedure. In combination these procedures permit the administrator to carry out start of day, close of day, check-in, maintenance, start service, restart service, and center message transfer functions. The testing workstation invokes a test delivery application which initiates and controls the testing session. The testing workstation is configured to execute a testing kernel and a testing station administration procedure. In a preferred embodiment the file server provides the only memory for the central administration workstation and the testing workstations. 
     The method according to the invention is carried out by first invoking the administrative system by logging onto a central administration workstation using a unique login ID. Then an input of appointment data identifying each examinee scheduled to take a test at the test center over some specified period of time is received by the adminstrative system. The administrator then verifies the appointment data associated with each examinee when the examinee arrives at the test center to take a test. At that time, the administrator provides an indication to the administrative system that the examinee is ready for testing. The examinee is then escorted to one of the testing workstations located in a testing room remote from the location of the central administration workstation. The administrative system then initiates the delivery of the standardized test to the examinee on the testing workstation. During the testing session, the examinee&#39;s responses are preferably recorded in an examinee performance file and subsequently transmitted to an appropriate post processing system so that the responses can be scored. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The present invention will be better understood, and its numerous objects and advantages will become apparent by reference to the following detailed description of the invention when taken in conjunction with the following drawings, in which: 
     FIG. 1 is a block diagram of a typical computer based testing arrangement; 
     FIG. 2 is a block diagram of the hardware architecture according to a preferred embodiment of the invention; 
     FIG. 3 is a block diagram showing one implementation of the administrative system within the computer based testing system according to a preferred embodiment of the present invention; 
     FIG. 4 is a block diagram of the software architecture according to a preferred embodiment of the present invention; 
     FIG. 5 is a functional flow diagram of the administrative workstation start-up procedure; 
     FIG. 6 is an example of the main menu displayed on the central administration workstation display; 
     FIG. 7 is a functional flow diagram of the Start of Day administrator procedure; 
     FIG. 8 is a functional flow diagram of the check-in procedure; 
     FIG. 9 is a functional flow diagram of the start service procedure; 
     FIG. 10A is an example of a check-in screen displayed by the central administration workstation; 
     FIG. 10B is an example of an escort message screen displayed on the central administration workstation; 
     FIG. 11 is a functional flow diagram of the administrative procedure for initiation and termination of the testing session; 
     FIG. 12 is an example of an examinee confirmation screen displayed on the testing workstation; and 
     FIG. 13 is a functional flow diagram of the Close of Day procedure. 
    
    
     DETAILED DESCRIPTION 
     FIG. 2 is a block diagram of the basic hardware architecture of a preferred embodiment of the administrative system at a testing center. As shown in FIG. 2 the hardware comprises one central administration workstation 5, a single file server 6, and one or more testing workstations 7. In a preferred embodiment, the central administration workstation 5 is an IBM PS2/35 having a minimum of 4 MB of RAM, a standard VGA monitor, a standard mouse, a 1.44 MB floppy drive and a Zoom 9600 baud V.32/V.42 modem with MNP for communications. The testing workstations 7, in this preferred embodiment are identically configured, namely, an IBM PS2/35 having a minimum of 4 MB of RAM, and a standard VGA monitor and a standard mouse. Testing workstations 7 preferably have no floppy drive so that unauthorized persons cannot copy information onto the file server 6 or copy data or files from the file server 6. 
     In this preferred embodiment, the file server 6 is an IBM PS2/57SX having a minimum of 8 MB of RAM, a floppy disk drive, an internal tape backup unit and a monochrome monitor. The central administration workstation 5 and the testing workstations 7 are connected via EtherNet to the file server 6, which preferably serves as the only permanent disk storage for the workstations to secure the files and data from unauthorized access or manipulation. It should be understood, however, that other compatible hardware can be used. 
     The Central Administration Workstation 5 is typically located outside the testing room and is used, for example, for the following purposes: 
     to perform system start up and shut down procedures; 
     to schedule appointments; 
     to check-in arriving examinees; 
     to start a test for an examinee at a designated testing station; 
     to restart a test after a testing workstation or general administrative system failure; 
     to provide routine system functions such as adding new administrators, changing the access rights of others, etc.; 
     to send pending files and transactions to an independent data center; and 
     to receive files and transactions for distribution to various software components. 
     Typically the testing workstations 7 are located inside the testing room. Preferably no central administration workstation features are provided on a testing workstation 7. A testing workstation 7, for example, provides the following functions: 
     Start a testing session; 
     End a testing session; and 
     Interrupt an in-progress testing session via command from the central administration workstation. 
     FIG. 3 is a block diagram showing an implementation of the administrative system 10 and its interfaces in a computer based testing system. When an examinee 20 registers to take a test, the independent data center 12 schedules the examinee to take a selected test at a predetermined test center at a specified time on a specified date. Independent data center 12 is managed by an independent testing service such as SKS. Information identifying the examinee 20 and the examinee&#39;s schedule arrangements are defined as the examinee&#39;s appointment data and are stored in a database at the independent data center 12. 
     In a preferred embodiment, a test center administrator will start-up the administrative system 10 on the test center&#39;s central administration workstation each day before invoking any testing sessions. During the central administration workstation start-up procedure, the independent data center 12 provides the appointment data to the administrative system 10 as shown in FIG. 3. Alternatively, an on-line registration and scheduling system (not shown) may be provided on the central administration workstation so that an examinee 20 may walk in to a test center and register prior to taking a test. The appointment data would be generated by the registration and scheduling system and provided to the administrative system 10 and the administrative system 10 would transmit the appointment data to the independent data center 12 to be stored in an appropriate database. 
     During a testing session, examinee performance records (EPR) are created for recording the examinee&#39;s activities while taking the test, e.g., the examinee&#39;s responses to the questions presented by the computer based test during the testing session. Event security log (ESL) records are also preferably generated each day. The ESLs would record information related to the security of the computer based system and tests such as the identity of the administrator who invoked the administrative system start-up procedure and the name of each administrator who initiated a testing session. Examples of the format and contents of EPRs and ESLs may be found in co-pending application Ser. No. 08/082,038. Additionally, in preferred embodiments irregularity report records (IRR) are generated to report any problems an examinee may have during a testing session with the equipment or problems related to conditions at the testing center during the test session, e.g., the testing room being too hot. 
     The EPRs, ESLs, and IRRs are transmitted to the independent data center 12 which provides them to a router 14. Router 14 then separates the records depending upon the record type. The EPRs are transferred to an appropriate Network Data Distribution System (NDDS) 16 which formats each EPR for scoring according to a testing-program specific format. An example of a NDDS and a description of this formatting procedure are described in co-pending application 08/082,038. The ESLs and IRRs are transferred to an operations center 22 so that equipment and security problems at the test center can be monitored. For example, daily activity reports can be generated from these records as described in co-pending application Ser. No. 08/082,038. 
     Testing program operations 18 scores the examinee responses and generates a score report for the examinee 20. The scoring system parameters depend upon the specific testing program, e.g., GRE, etc. Testing program operations 18 in a preferred embodiment receives IRR information from the operations center 22 so that examinees&#39; score reports can reflect any security or equipment problems identified at the test center during each examinee&#39;s testing session. 
     In a more preferred embodiment, the administrative system 10 is configured to receive on-line messages from either the operations center 22 or the independent data center 12 as shown in FIG. 3. Such an on-line message capability permits real-time instructions to be sent to an administrator at a test center in the event of equipment failure or security problems. 
     The administrative system architecture according to a preferred embodiment of the present invention is shown in FIG. 4. The administrative system architecture includes several subsystems which are run on either the central administration workstation or on each of the testing workstations. As indicated in FIG. 4, the Administrative Kernel 30, the start-of-day (SOD) subsystem 32, the close-of-day (COD) subsystem 34, and the start test subsystem 38 are run on the central administration workstation. The Test Station Kernel 40 and the Test Station Administration subsystem 42 are run on the testing workstations. 
     The Administrative Kernel 30 is executed by the central administration workstation&#39;s operating system as a result of the administrator starting the system. The following are examples of some of the functions it provides: 
     displays the system menu and executes programs associated with menu items; 
     displays messages for the system administrator which originate from the independent data center or operations center; 
     provides virus scan detection; 
     automatically runs the Close of Day (to be described in detail below) procedure if the system is left unattended overnight; and 
     provides access security via login to prevent unauthorized access to menu items. 
     The start-of-day (SOD) subsystem 32 is a generic title given to a program that is run as part of the system start-up procedure. Programs that carry out available administrative system functions are stored as profiles 50 on the file server at each testing center as required by the independent data center. The format of the profiles may include several fields including a field used to identify those function which are to be executed during the administrative system start-up procedure. One exemplary format for the profiles 50 is described in Appendix A. The SOD subsystem 32 checks the profiles to determine which functions are to be run when the administrative system is started. The SOD subsystem 32 also preferably down loads the appointment data from the independent data center. 
     The Close-of-Day (COD) subsystem 34 is preferably run before the administrative system is shutdown. It uploads the status of each appointment to the independent data center. 
     The scheduling/registration module 36 shown in FIG. 4 provides the ability to schedule a test, check-in an examinee, cancel a scheduled test and perform other similar tasks. It is preferably customized for the a particular test program or the particular testing service (e.g., SKS) which administers the computer based tests. Therefore, the scheduling/registration module 36 is preferably provided by the test producer or testing service. Consequently, the administrative system according to a preferred embodiment of the present invention does not include a scheduling/registration module 36 as indicated by the dashed lines in FIG. 4 but includes interfaces to the scheduling/registration module 36. However, it should be understood that a suitable scheduling/registration module 36 can be provided by the administrative system of the present invention. 
     The start test subsystem 38 consists of two software modules. The Start Service module, which displays the list of examinees who have appointments to take a test, and the Central Station Administration module, which is the generic name given to a class of programs that provide testing-program specific features prior to starting a test for a particular examinee. 
     The features provided depend upon the needs of the testing-program. For example, GRE tests require that a photograph be taken. Therefore, the GRE Central Station Administration preferably checks for the existence of a photograph. 
     The Start Test subsystem 38 produces the Job Info 49 and Job Data 51 files, which direct the Test Station Kernel 40 and Test Station Administration 42 respectively. The computer based test is available on the testing workstation after the administrator makes a final confirmation of the examinee&#39;s identification and appointment data. 
     The Test Station Kernel 40 is executed by the operating system as a result of the administrator starting the testing workstation. The following are examples of the functions it can provide: 
     confirm the date and time with the administrator; 
     allows the administrator to assign a station number to the testing workstation 
     responds to Job Info files 49 from the start service module of the Start Test subsystem 38, which runs on the central administration workstation; 
     displays a preliminary administrator confirmation screen; and 
     responds to `Kill Signals` from the central administration workstation, which cause the workstation to shutdown hurriedly--even in the middle of a testing session. 
     The Test Station Administration 42, is a generic class of software lying between the Test Station Kernel 40 and the Test Delivery Application 44. The functions performed by this component are determined by the needs of the testing program. However, its typical uses are a) to display an examinee confirmation screen, and b) to translate the administrative system data into the Test Delivery Application&#39;s standard format. One example of a Test Delivery Application 44 is described in co-pending, application Ser. No. 08/082,038. The Test Delivery Application 44 primary function is to execute the computer based test. 
     FIG. 5 is a functional flow diagram of the administration workstation start-up procedure. The administrator first logs onto the central administration workstation from the operating system using a personal login ID as shown at 60 in FIG. 5. This action invokes the Administrative Kernel. The Administrative Kernel&#39;s first task is to perform internal initialization at 62. In a preferred embodiment, the Administrative Kernel then verifies that important software and data files have not been corrupted. This can be done using commercially available virus scan detection software described in co-pending application Ser. No. 08/082,038. When the initialization 62 is complete the main menu shown in FIG. 6 is displayed at 64. The Administrative Kernel then waits for the administrator to select one of the menu options at 66 which include but are not limited to SOD 70, check-in 80, start service 90, COD 100, exit to the operating system 110, restart service 120, IRR 130, and center message 140. 
     If it is the start of a day, i.e. the system is not being restarted for instance after a power outage, the administrator will select the SOD option from the main menu at 70. This invokes the SOD administrator procedure which is shown in FIG. 7. The first and primary function of this procedure is to preferably call up the independent data center as shown at 72 to receive the appointment data. In a preferred embodiment, the SOD procedure is performed each day that a test will be given and the appointment data includes substantially all of the appointments for the day. The main menu can then be redisplayed as shown at 74. The SOD procedure and the start-up procedure run on the central administration workstation and are part of the Administrative Kernel. Detailed flowcharts and pseudo code for the Administrative Kernel programs are provided in Appendix B. 
     The SOD administrator procedure continues at the testing workstations. Next the administrator would enter the testing room and login to each of the testing workstations at 75, one-by-one, preferably using a different login than the login to the central administration workstation. The operating system then automatically executes the Test Station Kernel as a result of the login. As each testing workstation is started, the Test Station Kernel prompts the administrator to verify 35 the date and time and then enter a station number. The station number is checked to ensure that no other testing workstation is assigned the same number as shown at 76. When all of the testing workstations have been assigned a station number as determined at 77, the Test Station Kernel displays an appropriate idle screen and begins polling for a Job Info File as shown at 78. Detailed flowcharts and accompanying pseudo code for the Test Station Kernel programs are provided in Appendix C. 
     When an examinee arrives to take a test, the administrator selects the &#34;Check-in&#34; option from the main menu as indicated at 80 in FIG. 5. A flow diagram of the check-in procedure is shown in FIG. 8. This will invoke a corresponding check-in function of the scheduling/registration module as shown at 82 in FIG. 8. The administrator would then review the appointment data available through the scheduling/registration module with the examinee at 84 and provide an indication that the examinee is ready to take the test at 85. The main menu is then redisplayed at 86 and the Administrative Kernel awaits the next menu selection. 
     The next step would be to invoke the &#34;Start Service&#34; option from the main menu as shown at 90 in FIG. 5. A flow diagram of the start service procedure is shown in FIG. 9. The Start Service module displays the list of appointments at 91. The just-checked-in examinee would appear in a list as indicated on the screen shown in FIG. 10 as an example. The administrator selects the examinee from the list at 92. The Start Service module then invokes the Central Station Administration module for the testing-program at 93. 
     The Central Station Administration module performs any tasks required by the testing-program; for example, determining whether a photograph has been taken and prompting the administrator to take one if necessary, prompting the administrator to review critical identification information, etc. When all information is reviewed and completed, the Central Station Administration module one of the available subtests based upon internal rules and writes a Job Data File containing examinee and test delivery information. 
     More specifically, the Job Data File contains information required by the Test Delivery Application. Some examples of information contained therein are as follows: 
     Examinee&#39;s name; 
     Examinee&#39;s identification number; 
     Examinee&#39;s date of birth; 
     Examinee&#39;s social security number; 
     Authorization to test number; 
     A flag indicating whether this is a restart of a previously started but incomplete test; 
     A flag indicating the type of restart, if the above flag indicates restart; 
     A string containing the package name about to be delivered; 
     The package title (e.g. GRE General Test); 
     A string that describes where on the disk the package can be found; 
     A string that describes where on the disk the resulting Examinee Performance Record is to be written; 
     A count, possibly zero, of the number of dynamically selected testing components to be delivered; 
     The testing components themselves, if any; 
     A fully constructed Start Session Record of the Examinee Performance Record; 
     The Central Station Administration then exits and returns a code to the Start Service module. Detailed flowcharts and accompanying pseudo code are provided in Appendices D and E. 
     If the return code indicates that the Central Station Administration was successful, the Start Service module writes a Job Info file at 95 for the Test Station Kernel and exits. The Job Info File preferably contains two ASCII lines, a Command Line and an Appointment Number Line. The Command Line is preferably a fully qualified string containing a coldstart/restart indicator, the name of a testing-program, and any arguments it requires. The Appointment Number Line is a string containing the Appointment Number. 
     The Administrative System then displays an escort message such as the one shown in FIG. 10B. The administrator then would escort the examinee into the testing room to the testing workstation to which she or he was assigned. The Administrative System Kernel then redisplays the main menu at 97. 
     In the meantime, the Testing Station Kernel (on the testing workstation to which the examinee was assigned) will detect the Job Info File as shown in FIG. 11 at 150, process the information contained therein at 151 and display a preliminary confirmation screen at 152. 
     When the administrator arrives at the testing workstation, he or she reviews the preliminary confirmation screen and keys in a unique override key sequence at 153. The Test Station Kernel then executes the Test Station Administration program for the testing-program at 154, which is specified by the Job Info File at 155. 
     The Testing Station Administration reads the Job Data File 155 and displays the examinee confirmation screen at 156. An example of an examinee confirmation screen is shown in FIG. 12. The examinee reviews the information. 
     If the information is correct, the examinee presses ENTER and the Test Delivery Application (TDA) is started at 157. The Test Station Administration polls for a return status from the TDA at 158. When the Testing Station Administration detects the TDA return status, it is processed as follows: The Test Station Administration, then cleans up at 160 and, in turn, signals the Test Station Kernel, which cleans up and sets the appointment to the appropriate status. 
     If the test ended successfully, the Examinee Performance Record, photo, etc., are posted to the communications manager at 159 for eventual transmission to ETS. The Test Station Administration then cleans up at 160 and, in turn, signals the Test Station Kernel, which cleans up and sets the appointment status such that the appointment no longer appears in either Start Service or Restart Service. 
     Otherwise, the EPR, photo, etc., are retained and the appointment status is set such that the appointment appears in the Restart Service list (which will be described below) through which the test can be restarted. 
     If the information is incorrect, the examinee notifies the administrator at 156. The administrator enters the special key combination to force an administrative override at 161. This terminates the Test Station Administration, which returns an abort code to the Test Station Kernel, which, in turn, sets the status of the appointment accordingly. Detailed flowcharts of the Test Station Administration program and accompanying pseudo code are provided in Appendix F. 
     Testing sessions that ended abnormally, either through administrator intervention or system failure, can be restarted via Restart Service. The Restart Service module, displays the list of examinees who have had a testing session prematurely terminated. 
     As described above, the TDA provides a return status to the Test Station Administration subsystem. If the test was terminated prematurely, the Test Station Administration subsystem updates the Job Data File with the &lt;JOB&gt; parameter set to Restartable. Detailed flowcharts and accompanying pseudo code are provided in Appendix F. In a preferred embodiment, Restart Service merely allows the administrator to select a test to restart from the list. Upon selection an escort message as shown in FIG. 10B is displayed. When the escort message is confirmed by the administrator, a Job Info file is written--this time with a restart indicator--to direct the Test Station Kernel and Restart Service. The Job Data file created during the Start Service procedure is preferably reused during the Restart Service procedure so that no testing-program specific features are required to restart a test. The administrator would then escort the examinee into the testing room to the testing workstation to which she or he was assigned. The sequence of events at the testing station, namely, the progression from the Test Station Kernel, to Test Station Administration, to Test Delivery Application, is executed in a similar fashion as described above in connection with the Start Service procedure--except that each testing-program is notified that this is a restart for post processing purposes. 
     The sequence described above repeats throughout the day until the close of business. FIG. 13 is a flow diagram of the administrator&#39;s COD process. At the end of the testing day or other period of time defined by the testing service, the administrator re-enters the testing room and shuts down each of the testing workstations at 101. Returning to the central administration workstation, the administrator selects the Close Day menu item at 100, which invokes the COD program for each testing-program, if the testing program has one. 
     Many tasks can be performed by a COD program but some examples are as follows: 
     The status of all appointments is written to a log record at 103 and returned to the Independent Data Center at 104. 
     Any EPRs, photos, etc., for tests that failed and were never restarted are posted to the communications manager for transmission to the appropriate test producer also shown at 104. 
     The day&#39;s attendance files are deleted from the file server shown at 105. 
     When close of day is complete the Administrative System Kernel redisplays the main menu to await the next Start of Day at 106. 
     The administrator can then exit to the operating system by logging off of the administrative system as indicated at 110 in FIG. 5. For instance, an &#34;Exit to DOS&#34; button may be provided by the main menu as shown in FIG. 6. 
     An additional testing workstation feature which can also be made available is the &#34;Reassign Station&#34; option shown in FIG. 6. This feature may be used if one or more testing workstations become unavailable during the day due to faulty equipment or when the testing workstation is used for another purpose. The workstation numbers can be reassigned by selecting an appointment from a list of appointments that are not in progress and then selecting a station from a list of stations. Upon confirming the choices, the selected appointment is updated with the selected station number. 
     In addition to the &#34;check-in&#34; feature described above, the administrator may be provided with the capability to perform other administrative functions using the central administration workstation. For instance, some testing programs require the examinee&#39;s photograph to be taken prior to the examinee&#39;s scheduled testing session. The &#34;Image Capture&#34; button permits the administrator to capture the examinee&#39;s image and store it digitally with the examinee&#39;s identification and appointment data. Electronic image capture techniques are generally known to those skilled in the art. 
     Another administrative function which can be accessed by the administrative system according to a preferred embodiment of the present invention, is the &#34;Scheduling/Registration&#34; feature shown in FIG. 6. By selecting this button the administrator can access an on-line scheduling and administration facility which would permit examinees to register at the test center and schedule the test on a walk-in basis. However, the scheduling and registration software would preferably be provided by the testing service which administers tests at the particular test center. 
     The &#34;Irregularity Report&#34; button shown in FIG. 6 would be selected by the administrator when the administrator wants to generate an irregularity report. For instance, the testing service administering the test and the test producer may want to be informed when certain equipment failures cause an examinee problems during the testing session. As an example if the air conditioner at a testing center failed to work on a hot day, all of the examinees taking a test on that day may not perform as well as they would have if the testing room had been cooled. Therefore, such information is helpful to the testing program operations when scoring the examinees&#39; responses and is helpful to test producers which use the examinees&#39; responses for evaluating the tests that they have produced. The irregularity report may be generated by creating a log file having a format which can be identified as an irregularity report and writing a log record with the desired information to the file. 
     The &#34;Lock Screen&#34; button shown in FIG. 6 would be selected by the administrator when the administrator wants to generate and leave the central administration workstation unattended. This causes the Administrative System Kernel to display an idle screen. To unlock the screen the administrator must use the administrative override key combination which causes a login screen to appear and after successful login the main menu is redisplayed. 
     The &#34;Center Messages&#34; button shown in FIG. 6 would be selected by the administrator to review a queue of waiting messages. When selected the program preferably displays a short description of each message in the queue along with the security level required to read the message. The administrator selects a message from the list and if the administrator has the required security level the message is displayed. The administrator can then print or delete the message. After disposing of the message the list of remaining messages is preferably displayed. 
     The &#34;Security Maintenance&#34; button shown in FIG. 6 would be selected by the administrator password, or in the case of the highest level administrator to reset his or her to reset the password of any other administrator, or to add, delete or change login information for any administrator. 
     The &#34;Retrieve Data&#34; button shown in FIG. 6 would be selected by the administrator to copy backup copies of data that had been previously sent via the Communications Manager to the independent data center. When selected the program preferably displays a list of the data available during the last several days in which the system was in operation. The administrator then selects a day. The program then prompts the administrator to insert a floppy disk and copies the data transmitted that day to floppy disks. When complete the program exits. 
     The &#34;System Status&#34; button shown in FIG. 6 would be selected by the administrator to display, for example, the following information: 
     the date and time 
     center number and name 
     available disk space (in bytes) 
     communications status, namely, whether communications is on or off 
     station information, namely, whether the station is active or available, the examinee at an active station and the test being taken 
     a list of the installed functions, the status (enabled or disabled), and the function version. 
     The &#34;System Maintenance&#34; button shown in FIG. 6 would be selected by the administrator to apply system maintenance from a diskette. When selected the administrator is prompted to enter a diskette. The diskette is preferably checked to ensure it is a valid maintenance diskette and is intended for the center at which it is being used. If so, work orders are copied from the diskette to the file server and the program exits. In due time a background maintenance program is preferably executed by the Administrative System Kernel. The maintenance program detects the new work orders and applies them. A work order contains files or commands, and a delay flag that tells the maintenance program whether to apply the work order immediately or to wait for an active command (described below). A file may contain a profile, data, program, or any other system file plus the file&#39;s destination. The maintenance program `applies` the file by moving it to the specified destination. Examples of some possible commands are: 
     the enable command, which either enables or disables a function (profile) 
     activate and deactivate, which either activate or removes a previously sent but unapplied work order 
     deregister, which removes an installed profile and data associated with the profile 
     delete, which removes a specified file. 
     While the invention has been described and illustrated with reference to specific embodiments, those skilled in the art will recognize that modification and variations may be made without departing from the principles of the invention as described hereinabove and set forth in the following claims. ##SPC1##