Optimum Course Schedule Generator & Registration System and Finals Schedule Generator: Codename OptReg
Quang Tran (qtd@cs)
Spring 2006
CSE 403
LCO/Project Proposal
1 Operational Concept
Existing Problem
The process of generating a time schedule in a traditional university or college is basic and straightforward: There is a traditional system (whether human or computer) that takes in as input the courses that will be taught, potential conflicts that students might have in the courses (e.g. two CSE courses that students may take in the same quarter will not be scheduled at the same time), instructor availability, resources availability, classrooms and lecture hall availabilities and seat counts, and any other input. This traditional system then generates a feasible time schedule with the given input and allows students to register for the courses when time comes. A big problem with this is that there is none or very little student input on the time schedule creation, even if the college or university has one thousand, twenty thousand, thirty thousand, or even fifty thousand students. A student might really want to take a certain course, but the time that the course is offered may not be feasible for the student, so he doesn’t take the course at all.
A separate but connected problem is the finals schedule that students have at the end of the quarter. The traditional system takes in the list of courses being taught along with its time and location, and sets up a feasible final examination schedule such that no student has a time conflict to take a final exam, that no instructor has a time conflict administrating the final exam for two or more courses, and that no room conflict occurs such that two classes take the same final exam in an assigned room at the same time. A big problem with this is that there can be a student with an assigned finals schedule that forces her to take all of her final exams in the first day of the final’s period, all back to back (this has happened before in practice). This gives the student a great disadvantage as she must cram in all the material from all of her courses, and take all of her long exams back to back in a single day when her exams could have been dispersed throughout the final examination period.
Proposed Solution
With technology available today, I propose a solution to address these two problems using computer software and algorithms:
Software System: OptReg
Have a time schedule generator, codenamed OptReg, that takes as inputs from the traditional system (instructor/lecture hall availability, resource availability, etc) AND student input. That is, before a time schedule for the next quarter or semester is generated, OptReg will survey students on what he/she will be taking, and the preferred time he/she wants to take. OptReg will then generate a time schedule that takes into account of the administration, resources, and students so that everybody (or most people) will be happy with the generated time schedule.
OptReg will also handle registration of courses when students register for courses. A key difference with OptReg from the traditional registration system is that during registration, students can propose a different time slot for the course to be taught, and if that proposal passes all given constraints, the course will be rescheduled (this event may rarely happen as it will affect all students already registered for the course).
After the quarter or semester has started, and everybody’s schedule is stable and there are no more changes to a student’s courses, OptReg will generate an optimal finals examination schedule. The definition of optimal here is defined by the university, but will generally mean that the student’s final exams are dispersed throughout the examination period so that he/she can have time to study for the exams.
User Community: College or University faculty, staff and students
Goals: To have a time schedule for the college or university that will make as many people (students and staff) happy as possible (optimum time schedule)
Non-Goals: This is not a Student Services Portal like the MyUW. This software system only handles time schedule generation, registration, and final examination schedule generation. Also, currently, integration into the university’s system will not be done and can only be done on a case by case basis.
2 System Requirements
The system requirements are a simple and straightforward web application from the perspective of the users. The steps of the process are as follows:
1) Input from students, staff, and faculty on preferences and constraints of the time schedule is collected (Figure 1).
2) A feasible, optimum time schedule is generated
3) Faculty and Administration approves the generated schedule
4) The registration process begins for students
- Students can propose a new time for a given course
- If all constraints satisfied after feedback from other students, administrators, and faculty course time may change
5) Classes start
6) When no changes to student’s schedule are possible, an optimal finals examination schedule is generated and verified
Here is a sample mockup of how a survey to take input from students on preferred time would look like (Figure 2):
A similar page that requests preferences and constraints from administrators and instructors used to take input.
When an optimal, feasible time schedule has been generated and students register for a course, they have the option to propose a new time for the course (Figure 3).
The Final Examination schedule generator is the same as the traditional system, but it will find an optimal final examination schedule.
Other System Requirements
In order for this system to work, there must be a way to obtain data on prerequisites and restrictions of coursework from students for the Time Preference Survey and the registration restrictions. There must be a module in OptReg that takes in data from the university’s system for this to happen. Also, OptReg will be responsible for exporting the registration results and the finals examination schedule to the existing system in the university.
3 System and Software Architecture
This system can be seen as an “add-on” to the current student services portal, but has its own architecture to allow portability so that this system can be added on to many college and university’s system with little modification. OptReg will take in data (for now, a plain text file of data) of all the prerequisites and registration restrictions of each student to handle registration. This is a required part that the university must provide in order to handle course registration. Taking data from the university’s registration system will be a risk and must be dealt with in a case by case basis for different universities. This will be handled in the deployment part of the system’s life cycle, so we will not handle it for now. For now, I assume that the data given to us is a plain formatted text file because the goal of this software system is to provide an optimum time schedule, flexible registration, and optimum final exam schedule that does not exist elsewhere. The survey and registration web pages for the application will be written as part of OptReg and will be integrated into the university’s student services portal. This integration must be dealt with in a case by case basis also, but for now, I can assume that security will be handled by the university’s student services.
So basically, OptReg will provide the web page to handle the survey for time preferences, course registration, and final exam schedule. OptReg will depend on data from the university to handle registration. OptReg will export a file (plain text) of the registration results and final examination results to the university system for its own use.
The technology used will be ASP .NET with C# to build the web application using Visual Studio .NET. IIS web server to run the web pages will also be required. No database access is necessary because all the required data is obtained through the university’s system via a text file.
4 Life Cycle Plan
Who wants it? Students, Faculty, Administrators
Who will develop it? The development team will consist of 6-8 people. Their roles will be developers, architects, researchers, and testers
Who will integrate it? The university’s technical staff along with the OptReg development team. Integration will not be a part of this system as we do not know which university will employ this system
Who will maintain it? The university’s technical staff along with the OptReg team will maintain it
Why is the system being developed? To get student input on how the course time schedules will be generated. To generate a finals exam schedule that will be feasible for students.
What will be done? When (High Level Timeline)? The web pages that survey the students, the generated time schedule, and the registration pages will be done. The finals exam schedule will also be generated. The plan is, out of the 8 weeks given for development, Week 1 will be the completion of the user interface and architecture, Week 3 will be the completion of the main algorithms and logic of the program to generate the schedule, Week 5 will be the completion of the registration system, Week 6 will be the completion of the optimum finals exam schedule, and the final weeks will be for anything else.
Who will do it? When? This can wait until we have the teams
How will the job be done? This can wait until we have the teams
Resources? 6-8 team members, 8 or 9 weeks, an IIS web server, Visual Studio .NET with ASP .NET and C#.
The team must have members with knowledge of developing ASP .NET web applications, C#, and algorithm design.
5 Feasibility Rationale
Assumptions
-Data regarding courses, registration restrictions, prerequisites, and individual student information is in a large text file. When this system is actually deployed, there must be a way to get the data from the school. We do not handle deployment, but our system will assume the text file in a given format.
Risks
-Our algorithms to generate the optimum time schedule and finals exam schedule may take a long time to run. Possible solution: Get the general framework of OptReg done as soon as possible and spend more time on researching and designing a fast, efficient algorithm.
-Integration with the university’s student service system will be a definite risk that will not be handled in this project. It will be handled in the deployment process after we’ve sold this idea to an existing university
-The generated optimum time schedule will not be a significant increase to the university’s current existing time schedule. This requires pilot testing before any practical marketing is done