The Question Management section of this program should mostly be encapsulated in a "Question Database" object. This object holds a collection of questions and the questions themselves then hold all the information pertaining to a question in the question database. Most of the operations for Question management are very simple. For example the add, delete, and edit operations. A search operation is also needed which will be a little more difficult to implement with the search on keystroke (such as in iTunes). Some information that may be helpful when implementing the Question Management pertains to the question type and multiple answers or questions text fields (such as in the fill in the blank questions or the multiple choice question). The type field of a question should be a simple enumeration telling the program which type of question it is, and by knowing that the program should know how to parse the question text and question answer to pull out multiple answers, etc.
The TestPackage module is
responsible for the user interface of a test, mainly the visual display of the
test, and the Replace question manipulation operation. All other question
operations are handled by the QuestionManagement module. There shouldn't be many
implementation pit-falls when dealing with the TestPackage module, with the
possible exception of the drag-and-drop feature of questions from a database to
the test.
The TestGeneration module is responsible for the user interface of
the automated test creation, and the process needed to filter questions from a
database and apply them to a test. Though the RSL logic may look a little nasty,
there doesn't appear to be any major pitfalls, as most of the database filtering
is fairly straightforward and could be handled (while very slowly) by simply
doing multiple iterations of a database until the test is full.
The syncing portion of the tool as we have specified it should not be too difficult. Issues that will need to be addressed are the location of the central question server and how to specify what IP it is at (possibly in a preferences menu), security (whether or not syncing will require a login), and network procedure (encryption, security protocol). These issues will be left to the implementers. As long as the pre/post conditions of the specified operations are met, the syncing feature of the TestTool should work as planned.
A difficult aspect that the implementer will have to deal with is how the proctor's computer will "take control" of the students' test-taking computers on the LAN. The proctor should have ultimate control over the students' test-taking sessions at all times – having the ability to pause, stop, and add time to tests remotely. Also once the student test-taking application is running on the student's computer, all other operations must be locked out. The student may not navigate away from the testing application or use other applications. Though building an application that completely takes over the student's computer may not be possible, the implementer must make the best effort to ensure that the student doesn't have access to other resources on the computer during testing.
The TestGrader module is only has a few complex features. The main object is the gradedTest which includes a gradedQuestion both have a few additional features. The most complex operations are the gradeSingleTest and gradeAllTests. When a single test is graded, all automatic questions are graded including multiple choice, true/false, and fill-in the blank questions and then the first essay or code question is displayed for grading manually. When all tests are graded at once, the automatically gradable questions are all graded and the question by question grading format is entered. Each question on the test is graded for each student and then moves onto the next question in the test.
Up: Functional Requirements | Top: index