The software (selfpace.mdb) is a relational database application that runs on top of Microsoft Access. Specifically, selfpace.mdb is a collection of tables, forms, queries, macros, and modules that, when loaded into Access, becomes a "test bank" system for creating, editing, managing and printing large collections of test items, tests, and answer sheets.
Although the distribution includes about 30 sample items in 5 sample groups, the tables are mostly empty. In other words, the software does not include the test items themselves.
To make any use of it at all you will need to have a copy of Access 97 or later. To make full use of it, you will also need a copy of Microsoft Word, version 97 or later. We are distributing the Access 97 version because it is the most widely available and provides a least common denominator. If you have a later version of Access, the code should automatically convert when you first load it.
Both Access and Word are included in "Microsoft Office Professional", but Access is not included in some of the other Office packages, such as "Small Business".
The software is copyright (c) 2001, by Austen Clark. It is distributed under the "copyleft" provisions of the GNU General Public License. A copy of that license is posted on the Self-Paced project website and included in the documentation package. The original can be found on the GNU website.
The software is distributed in the hope that it may be useful, and that it may further the cause of self-paced pedagogy; but it is provided AS IS, WITHOUT ANY WARRANTY OF ANY KIND, expressed or implied. In particular there is no warranty of merchantability or fitness for any particular purpose. See the GNU General Public License for more details.
The software is also distributed without any promise or offer to provide software support of any kind. The "Self-Paced Project" was an educational endeavor funded by the University of Connecticut for educational purposes only. Users of the software should understand that the Project has expended all of its funds; that it has no assets; and that it has no paid employees. If you elect to use this software, you do so entirely AT YOUR OWN RISK.
As described in "resource requirements for a self-paced course", the purpose of the software is to make it easier to manage the items and tests you need in order to teach a large self-paced course semester after semester. We use it at the University of Connecticut to edit and correct old items, to input new ones, to manage test-plans, and then to design and print a batch of 36 new tests each semester. We print answer sheets for the teaching assistants at the same time.
Before it became self-paced, this course required writing seven one-hour exams each semester: three one hour exams during classes (with three separate make-up exams for those who miss them), plus a final exam. Using selfpace.mdb I spend about the same amount of time putting together tests for the semester, but can create 36 tests instead of just 7. In that sense the project is a success; the technology "works".
In our project all the tests are delivered in the traditional way: they are printed on paper; students write their answers on those pieces of paper, and the teaching assistants grade the tests by hand. They put marks on those pieces of paper, add up the results, and only use the computer when it comes time to let the student know what the grade was. One reason for this traditional approach is that the test items include a full gamut of different kinds of items, including some true/false and multiple choice, but consisting largely of short answer, symbolization, truth table, and argument diagram problems. (See the study guides.) Some test items in a course on "critical thinking" could be graded by a machine, but most of them could not. For example, I don't see how the skills of criticizing an inadequate definition or providing a suppressed premise could be adequately tested using multiple-choice questions. We did not want to confine the skills we were teaching to those that a machine could check.
Nevertheless, for certain kinds of items, the database would allow web-based testing, and even machine grading. It has the granularity needed to make those possible someday.
Because Access is a full relational database, test items can be of any kind the user can create. There are no built-in limits at all. The system supports "data access objects", so that both items and answers can be something other than text: tables (truth tables), diagrams, pictures, etc.
There are "input screens" for all the various sorts of data items one needs to enter to create and manage a set of tests for a semester. We found that those screens are fairly awkward, however: most people prefer to create tests using a word processor. We created a "data loader" system so that tests that were already created in word processing document files could be chopped up and entered into the database without too much trouble. The system requires the user to go through the file and insert "macros", or command abbreviations, which tell the system how to cut up a file and put its various bits into the different fields of the database.
The macro system is extensively documented in the documentation package. We shifted to using that same system for entering new items as well. Teaching assistants now receive dummy "script files" for each unit; they edit those script files in a word processor to write their sample tests. In the course of the semester I run the resulting files through the data loader. In this way the teaching assistants do not need to learn the database system at all.
When you click "print test" or "print answer sheet" the system produces a stream of stuff that it sends directly into Microsoft Word, which fires up automatically. The stuff can include both text and "data access objects" such as truth tables or diagrams. (It is because we wanted to handle the latter that we decided to make the tie-in with Word. If items were pure text the output could be a pure *.txt file.) In any case you need Word to take advantage of this feature; and the output needs some final editing in any case before it is presentable.
The system allows the same underlying items to be used in tests for different courses. A given user can construct plans and tests for several different courses, and the groups of items for those different courses might overlap partially, completely, or not at all. For example, items for symbolization in sentential logic might be used both in a critical thinking course and in a symbolic logic course. This is why logging onto the system requires both a user name and a course name: your "view" of the data (of the groups, plans, etc) changes depending on which course you are working on. A group of items defined for one course is not visible within another one, unless it is explicitly imported into it.
The system asks for a password when you log on. It maintains a table to keep track of all the different authors of items within it, and each such author can be given a logon password and varying levels of access to the innards of the system.
We did not design the system for multiple concurrent users, however. Access is not very good at concurrency, so for now it is built on the assumption that there is just one user at a time.
There are various test bank products that are available, but none of them are as flexible as a system built on top of a full relational database. The latter gives you an extraordinary degree of control over every element. There are no built-in limits at all on kinds of items or types of answers. Tables and fields can be redefined and extended in a very flexible way. The key is to get the data organized into relational tables, and Access seemed a good front-end for doing this. Once the tables are well defined, they can be moved into a more powerful database system later, as the need arises.
The Self-paced Logic Project homepage.
Austen Clark's homepage.
The Philosophy Department homepage.