################################################################################
| Version 1.0 By Rajiv Mathews |
| Version 1.1 By Ravi Shankar.T |
| |
| |
| |
################################################################################
Note: Change Log would reflect the deviations from the previous version only.
Change Log
1. WHAT LICENSE DO WE USE FOR THIS PROJECT?
2. Inclusion of predefined par. Defined TT as start point and minimal scattering idea.
3. Complexity Ageing in Questions.
4. Comments in Grading
5. Merge / Import Question Database.
6. Up scaling downscaling in Grading
7. Comments in Stats Generator?
8. Comments in Teacher Info Db at b, c, f and g.
9. Teacher attendance in class course information.
Licenses are a important decision in the project design as this will impact the way we'll go about designing it and the way be develop it further(Which we hope we do). This decision has to be taken NOW, since sites like sf.net and the like require us to state a license for our project.
Red Hat Linux Project
Overview
Automated Time-tabling with an overall information management
system for maintaining department details and teacher-student
information
The overall system can be broken down into the following
major components
1) Automated Time-tabler
2) Automated Question paper generator
3) Automated grading system
4) Stats generator (Not decided as of yet)
5) An Automated Messenger
BASIC FEATURES of each of the components
1) The Automated Time-tabler, is to produce, well, a time
table (schedule for classes) based on the "input constraints".
The "input constraints", could include
a) Preferences
-- morning hours, stuff like that
constraints if any, unavailability
of a prof during certain hours
b) Number of hours for a particular class
c) Credits the particular course carries
d) Laboratory/ Theory/ Tutorial
The Time Table also has a facility to start from a partially defined Time Table the is keyed in from which it will try to generate a valid timetable. It should also be able to accommodate changes to valid/invalid solutions and find out a soln. How about something like "Class Advisor Lecture Hour should always be the first hour"? Should we allow this?
A non-primary Goal of this component would be to produce a timetable that scatters periods as little as possible, i.e., to produce a timetable that is as compact as possible (with respect to classes).
2) Automated question paper generator is, an optional tool,
available to all teaching staff. It would be maintained by that
particular entity themselves.
The basic components that it would include, would be
a) Data bank of questions, of the entities choice
Broken down on their own choice, as maybe,
a) In terms of complexity
* Hard
* Average
* Easy
OR by numbers like in MIPT :)
b) Or possibly, *genre* if it can be called that
* Problem
* Theoretic
* Essay type
The complexity of questions should decrease with the frequency it occurs, i.e., the notion of complexity is a 'relative' measure, something that's remotely like the ageing in Process scheduling (for the Lack of a better simile).
Options to merge / import question bank or other Faculty.
3) Automated grading system, would use the input marks, and based
again on the "parameters", it would assign grades to the particular
student
The "parameters", could mean,
a) Relative grading, where in further inputs would
be what percentage or percentile of the class is
graded superlative, and so on...
b) Absolute, where in the inputs would include what
mark and above would qualify for a particular grade
c) "Do I like that kid?" // is this REALLY necessary?
d) Up scaling /downscaling
4) Stats Generator:
This is one feature, which *could possibly* include
a) Generation of statistical graphs, that could
possibly judge
* the overall class performance
* the teachers performance
* variation in marks of the class
// This is Still Too Vague ...Damn I brought this Up in The First Place didn't I?
// How About Data Mining?
INTERNAL DATABASES that need to be maintained
---------------------------------------------
The four components above will work in sync with the databases that are
at the bottom. Listed below are the component databases that could play
a role in each of the above automated processes.
a) A teacher information database
This would contain general information of the teaching staff.
This could include,
a) Their general preference in teaching particular courses.
b) Courses that they *can* teach // Can? What does that mean willing? or Capable?
c) Preference in terms of when they would *like* or *not like*
Their classes to be scheduled. // Does this have to be in the DB? Wouldn't this change (very often)?
d) Any other commitments that they may have, which might make
them unavailable for a particular time slot.
e) TRA/Lecturer/Ass.Prof/Prof (HOD?) this again has to be that
Out, do we make this a factor in allotting preferences?
f) Courses that they have handled in the past, this way while
The administrator decides who handles what, he has options to
Choose from // refer to b)
g) Question bank -- this should be split into different fields,
So, while generating a QP he/she can select what kind of
Question paper they want. // What about storing Complexities?
b) Class and course information
This would include basic one-time entry (modifiable) data, that
will assist in the time-table generation and for the teacher,... blah blah blah
This could include
a) List of courses that are available to a particular semester
b) course details
* course id
* course name
* credits
Apart from the above, which would act as input parameters in the automation
process, there would other *temporary* data, that would be stored in the
database
a) Students marks
b) Student attendance
c) Teacher attendance // This is maintained anyway, so why not automate it?