This draft document describes the high-level project requirements for the fall 2010 section of this course.
As a part of the TUBBK (The Ultimate Blackboard Killer) initiative, Gradebook NG will manage all aspects of grading a collection of academic courses, in particular, storing grades and communicating them to their recipients.
Courses can have multiple instances (sections), each of which is taught by one or more instructors.
Every section has its own breakdown in terms of gradable items, optionally grouped by categories. This should be configurable on a per-course-instance basis.
Gradable items should be weighted, and this information could be used, for example, to automatically compute the final grade.
You should not assume that all of the categories are pre-defined. It is true that most courses have quizzes, homework, and projects. But every course is different in terms of its content.
(To keep the scope of this project manageable, the system will not include a mechanism for submitting work to be graded.)
An important question is how do people get into the system initially. At many institutions, the instructor is given a roster with all pertinent student info (student ID, contact phone number, etc.)
This information could be used to authenticate a user who wants to submit for the very first time. A student enrolls simply by providing his e-mail address and answering some information. (Last name, last few digits of ID, and perhaps one other piece of information.) An e-mail is sent that, if not acknowledged, will result in non-enrollment in the submission system.
Of course, ideally, the instructor may also enroll a student, but the whole goal in developing any such application should be self-maintenance.
To keep the scope of this system manageable, enrollment is performed by an administrator.
Students should be able to see all of the graded items in real time once the items have been released. (Workflow for approval and notification can be added for extra credit, please see below.)
Instructors and teaching assistants (TAs) should be able to see grades in table format.
Instructors and TAs need the ability to enter grades easily using suitable forms. For some items, such as exams, a batch-entry mode is needed. For others, such as programs, single entry is needed, because the TA (usually) will write a detailed report and justification for the grade.
Whenever dealing with list-like structures that the user is allowed to modify, the following edit operations should be supported:
The capabilities listed here refer to various entities whose detailed descriptions can be found below.
A student can
A TA or grader can
An instructor can do everything a grader can do, plus
An administrator can
A user has the following attributes
A class section (instance of a course) has the following attributes
A gradable item has the following attributes
A category is a symbol or tag with these attributes
When an item is graded by an instructor or teaching assistant, the grade does not necessarily get published to the student immediately. Therefore, it is essential to think about the workflow model somewhat.
Specifically, the system could be configurable how grades flow to students. If a TA gives a grade, some instructors want to see the grades before publishing them. Modelling such ideas is a well-known technique known as workflow.
In particular, the system could be set up to allow an instructor to approve a grade on a per-student basis or for an entire gradable (the student(s) affected are notified by email of the availability of their grade(s)).
A mechanism for students to dispute a grade. The system allows the student to enter an explanation of the dispute and notifies the instructor(s) by email.