1 / 14

A partially automated class scheduling system

A partially automated class scheduling system. This case study is adapted from Prof. Pankaj Jalote’s book. The overall objective. Collect options from instructors Schedule as per constraints and options

vea
Download Presentation

A partially automated class scheduling system

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. S P Pal, Jan 2002 A partially automated class scheduling system This case study is adapted from Prof. Pankaj Jalote’s book.

  2. The overall objective • Collect options from instructors • Schedule as per constraints and options The manual process conducted by a secretary is to be partially automated. The acquisition of options will be done by email. Options data will be put into a file. Other constraints’ data will also be available in files for the scheduling software. S P Pal, Jan 2002

  3. The scheduling software • Scheduling satisfying class capacities and rooms allotments not clashing in time. • Preferences must be scheduled by software in the order or submission by instructors. • PG courses are scheduled before UG courses. • Courses without preferences to be scheduled at the end. • Output schedule must be stored in a file. • Errors in preferences must be reported and no optimization of schedule is needed. S P Pal, Jan 2002

  4. DFD for the schedule process UG courses Separate Schedule UG PG courses Courses without schedule Schedule PG Schedule rest Collected forms S P Pal, Jan 2002

  5. Data dictionary • collected_forms =[instructor_name + course_name + [preferences]*] • schedule =[course_number class_room lecture_time]* • in the new automated system, we call the collected_forms as preferences_file • we also need a database of departmental information, called department_database • the new data dictionary will be as follows S P Pal, Jan 2002

  6. DFD for the automated system preferences_file Conflict Report Instructors, Secretary, Chairman Schedule Send E-mail Combine Into File Schedule Department_database S P Pal, Jan 2002

  7. Data dictionary for automated system • preferences_file =[preference]* • preference =course_number + enrollment + [preferences]* • department_database =[class_rooms]* + dept_course_list + [valid_lecture_time]* • class_rooms =room_no + capacity S P Pal, Jan 2002

  8. The requirements specification document • Abstract: Scheduling courses given lecture times, classrooms, preferences and constraints of departmental resources. • 1. Introduction • 1.1 Purpose: Describe all external requirements and interfaces for a course scheduling system. • 1.2Scope: Agreement, validation of final system delivered, changes to be made with permission of client/customer/user. • 1.3Definitions: Acronyms, Abbreviations. • 1.4References: S P Pal, Jan 2002

  9. SRS document (contd.) • 1.5 Developer’s responsibilities overview: developing, installing, user training, maintenance. • 2. General description: 2.1 Product function overview: 2.2 User characteristics: 2.3 General characteristics: 2.4 General assumptions and dependencies: S P Pal, Jan 2002

  10. 3. Functional requirements • 3.1 General description of inputs and outputs: Two files for input and two file for output. Input_file_1: List of room numbers with capacity; List of all courses; List of valid lecture times. Input_file_2: Information about courses being offered, specifying course number, expected enrollment and number of lecture time preferences. S P Pal, Jan 2002

  11. Functional requirements (contd.) • Output_1: Class numbers and time of all schedulable courses. • Output_2: List of courses that could not be scheduled with reasons. • 3.2 Functional requirements (detail) • 1. Determine time and room number for courses such that: 1.1 Only one course in one room at any time 1.2 Class capacity more than expected enrollment S P Pal, Jan 2002

  12. Functional (contd.) • 1.3 PG courses preferred over UG courses • 1.4 Process courses in the order as in input and try all preferences in order. Erroneous priorities must be discarded and absence of priorities would allow freedom of choice. • 1.5 No two PG courses must be scheduled at the same time !!! S P Pal, Jan 2002

  13. Functional (contd.) • 2. Courses with no preferences must be scheduled in any way, not contradicting above requirements. • 3. Produce list of courses which could not be scheduled due to constraints, giving reasons • 4. Check data in second input file against data in first input file. Messages for improper input data. Ignore invalid data items. S P Pal, Jan 2002

  14. Functional (contd.) 3.3 Detailed input file format 3.4 Detailed output file format 4. External interface requirements 5. Performance constraints 6. Design constraints 7. Acceptance criteria S P Pal, Jan 2002

More Related