################################################################################ | 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?