140 likes | 156 Views
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
E N D
S P Pal, Jan 2002 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 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
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
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
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
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
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
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
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
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
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
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
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
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