TRINITY PROJECT PROPOSAL. James DeBolt Valiant Tsang

Transcription

1 TRINITY PROJECT PROPOSAL James DeBolt Valiant Tsang SYST 699 Spring 2017

2 Table of Contents 1. Introduction Background Problem Statement Scope Assumptions Preliminary System Requirements Technical Approach Systems Engineering Solution Methodology Software/Schedule Tool Development Integration and Testing Project Management Project Schedule Communications Plan Deliverables Tool and User Manual Website Final Report and Presentation References

3 1. Introduction 1.1. Background The Trinity School at Meadow View is a small, private secondary school in Falls Church, Virginia. The coed school has approximately 150 students in grades seven through twelve. The school teaches a core curriculum to the students with little to no variation from year to year. Like other educational institutions of similar size, the Trinity School faculty engage in the activity of developing the class schedule by matching the teachers to the courses to the facilities and rooms to the time of day in which the courses are taught Problem Statement Commercial software exists for the development of schedules; however due to fiscal constraints, the Trinity School faculty develops the class schedule manually, using pen and paper. This is a manual, time-consuming, and cumbersome process that takes place twice per academic year Scope The scope of this project is to deliver a tool that will produce the class-teacher schedule that does not violate scheduling constraints such as those pertaining to teacher availability, class room size, or course curriculum rules. This effort is not to produce an optimized schedule, but for the tool to generate feasible schedules. The project team will build upon a previously developed Microsoft Access based application. Business constraints that were not previously implemented will now be incorporated. Additionally, the user interface and user experience will be enhanced Assumptions The following are assumptions that are being taken into consideration for the development of the system: The actual assignments of teachers to their courses are predetermined prior to using the system. The system will allow the user to pair teachers and courses to facilitate the development of the schedule Classroom name/number and classroom capacity will not change Preliminary System Requirements The following are preliminary system requirements that have been captured or derived and define the Trinity School Scheduler s (TSS) capabilities and constraints Functional Requirements The system shall have the capability to allow the user to enter information to include, but not limited to, the following: Teacher name Teacher availability Course names Number of students per course 2

4 The system shall have the capability that allows the user to delete user inputted information The system shall have the capability that allows the user to edit user inputted information The system shall be capable of producing a table of user input to provide status of teacher-course pairing The system shall be capable of producing at least two feasible schedules based on user input The system shall be capable of producing the output in tabular format The system shall be capable of storing user input. It will not require re-entry of identical information after compiling and executing the program Other Requirements The system shall incorporate scheduling constraints in accordance with information provided by the project sponsor These scheduling constraints presented in a spreadsheet shall be transcribed to ensure the constraint is accurately captured for incorporation. 2. Technical Approach 2.1. Systems Engineering The project team will liberally follow the V-model process for the development of the TSS. In trying to employ some practices related to Agile development, flexibility is required at that the beginning of the process for the purposes of minimizing lost time that would be related to a rigid process. For example, while research and analysis of the requirements are not complete, the project team will already be engaged with the design and development of the user interface and the coding to integrate the linear programming solver. On the backend of the V-model process, the project team will be more rigid with the testing, integration, and verification and validation to ensure all requirements are incorporated into the tool, full functionality of the tool, and that the tool meets the needs of the project sponsor. Figure 1. TSS Systems Engineering Approach 3

5 2.2. Solution Methodology School timetabling is an effort to develop a schedule of all the classes for the school by avoiding scheduling any one teacher in different classes at the same. As simple as it may sound, this has been a research topic for many years which includes significant time spent on automating the process. Many algorithms and techniques such as integer programming (IP), constraint programming, greedy algorithms, heuristic algorithms, and hybrids of techniques have been developed to address this problem set. A possible reason as to why there has not there been a single best solution to the school timetabling problem is the uniqueness of the constraints from one academic institution to another. Constraints are categorized as hard or soft. Hard constraints are the restrictions to which a solution must abide to while soft constraints are preferences. For a feasible solution, violation of the soft constraints is acceptable. Having deconstructed and analyzed the existing TSS, the current solution is to continue to use the IP approach to the school timetabling problem presented by the project sponsor. Due to the uniqueness of the school s curriculum, limited facility space, and teacher availability, all constraints will be considered hard Software/Schedule Tool Development The project team will use as much of the existing software and will add in additional functionality to enhance the tool to more completely meet Trinity s needs. The tool s functionality is realized in four primary phases: inputting requisite information into the user interface, formulating the integer program, solving the scheduler problem, and then creating the output TSS User Interface The existing TSS User Interface (UI) was developed using Microsoft Access Visual Basic for Applications (VBA) forms. The UI was designed with the intent that clerical, nontechnical staff should be able to easily generate a schedule with minimal training. The current version of the TSS does not meet this goal, and the project team will work to make the workflow more intuitive and less error-prone. Rather than allocating the team s available man-hours towards a complete rework of the UI, more effort will be made towards making modifications and bug fixes against the current functionality. Screens currently exist for accepting user input into some of the database tables that back the application, but not all allow tweaking of all pieces of data (such as renaming teachers or deleting data points). These forms will be reworked to allow straightforward modification of every piece of data that should be editable by the user. The homepage will be tweaked to allow input for the number of desired schedules to be generated. Additionally, the link out to the solver will be enhanced to call the new Java solver integration tool, passing along the current IP data and number of desired schedules. In order to support several new rules which must be considered by the solver, the team will create and expand database tables to facilitate new information from the user. These tables enhancements will be made with corresponding UI enhancements which allow for input, modification, and deletion of that data. 4

6 Integer Program Solver The existing TSS uses a MS Access VBA script to construct and output the Integer Program in the.mps file format. This MPS file would then be uploaded to the NEOS web server for processing, and the results would be ed to the user. However, this is a time-consuming, manual, and error-prone process. The current average run time for schedule generation on the NEOS server is only 2.02 seconds, which means that a relatively small amount of processing power and time is necessary to run the solving algorithm. Rather than incurring the time and complexity overhead of performing this process manually, the updated tool will instead rely upon the user s desktop to perform the optimization. The project team will integrate an appropriate Java library that includes solver functionality into a custom Java process which will accept the existing IP output file, perform the solving, and then save the results locally. Additionally, this Java tool will be able to automatically open the TSS Output Interface and set the appropriate file-path variable to the newly created output file. This will remove all need for 1) converting the Access IP output into MPS 2) opening a browser, navigating to NEOS and providing all of the pertinent information and uploading the MPS file, 3) waiting for the result file to be ed, and 4) needing to modify the output file and configure the TSS Output Interface to find it. Instead, all of this be performed behind the scenes by the Java application, while the user can take a few minutes to grab a coffee TSS Output Interface The TSS Output Interface is a MS Excel-based tool that allows the user to construct a human-readable schedule from the.sol formatted output of a solver tool. The homepage of this tool allows for a single click to update the excel sheet s records with all of the input values that had been provided to the TSS User Interface. These values are then used when the user navigates to the Master Schedule tab which allows for schedule export to PDF. The master schedule is a student-oriented view which shows separate junior high and high school schedules, showing each student cohorts daily schedule. Another available output from the TSS Output Interface is the Teacher Schedule which provides an ordered list of Teacher, Period, Student Cohort, Class, and Classroom combinations. This teacher-oriented output allows the user to easily display each teacher s workload Integration and Testing The TSS will no longer require external integrations with external code or websites except for the solver libraries included in the Java-level processing. This integration will be achieved within the code via the use of publicly available API s exposed by the Java Archives (JARs) which will be imported into the code. This integration, as well as the whole of the UI and database changes, will be verified according to the test plan. Testing will be performed, both internally and with the sponsor, to ensure that requirements have been satisfied. Test cases will be created to cover each of the requirements outlined in Section 1.5, and use the end-to-end functionality of the TSS via utilization of the TSS UI, the Java solver, and the TSS Output Interface. Additionally, the final outputs of the master plans and corresponding teacher schedules will be checked for compliance against scheduling criteria and will be submitted to the project sponsor for approval. Specific attention will also be paid towards validating that the total execution time is acceptable, as one of the risks incurred by this development is performance risk since 5

7 solving will be performed by the CPU on the user s machine instead of a remote server. This testing will also involve qualitative components regarding the appearance of the UI and ease of use (ensuring that a user with no training and just the guide would be able to sufficiently generate schedules using the TSS). 3. Project Management 3.1. Project Schedule The project schedule reflects the planned activities and milestones associated with the TSS project. As noted in above in section 2.1. Systems Engineering, the project schedule reflects the desired flexibility with overlap of tasks associated with researching and refining requirements with the design and development of the tool. 6

8 Figure 2TSS Project Schedule 7

9 3.2. Communications Plan The project team will establish regular bi-weekly meetings with the project sponsor. The intent of the meetings will be to ensure that the requirements (specified and derived) are agreed upon, that the user interface and tool workflow are acceptable, and to provide general status and progress of the project. 4. Deliverables 4.1. Tool and User Manual The tool will be delivered in three parts. The TSS UI will be delivered as a Microsoft Access Database file, the java solver will be delivered as a Java archive file, and the TSS Output Interface will be delivered as an excel workbook. These will be bundled together in a compressed zip folder which will allow for faster file transfer. Also included in this zip will be a Java Runtime Environment (JRE) installer which will be necessary for running the solver. The zip will be accompanied with a PDF-formatted Tool User Manual which will document the steps necessary to configure the user s PC and then launch and utilize the application. Configuration steps will include unzipping the tool zip folder, installing the JRE, and adding a Windows Environment Variable. The tool usage part of the manual will include all of the steps necessary for configuring the term-specific information (e.g. classes, classrooms, teachers, etc.), launching the schedule generation, and then interacting with the output UI to complete the process Website The project team will create and deliver a website to be hosted on the George Mason University domain which will serve as another point of documentation for the project. This site will include a page for describing the background and approach to the problem that the development is intended to address. Another page will provide brief biographies of the team members and their technical backgrounds as they contributed to the success of the project. This site will also host a downloadable version of the final deliverables, so that the tool can be utilized without the need for physical storage media such as a CD or flash drive Final Report and Presentation The project team will deliver two final documents for the benefit of the class and sponsor to communicate the summation of the Systems Engineering process embarked upon by the team in the pursuit of accomplishing this project. The final report will include information similar to the proposal, but with updated final figures and extra information about final design solutions and screenshots of the tool in action. The final presentation will convey similar information in PowerPoint format. 8

10 5. References Schaerf, A (1999a). A survey of automating timetabling. Artificial Intelligence Review, 13(2), Pillay, N (2014). A survey of school timetabling research. Annals of Operations Research, vol. 218, issue 1,

11 Approval from Project Sponsor By undersigning below, project sponsor acknowledges and accepts this proposal for the development of the Trinity School Scheduler. Project sponsor also acknowledges that the scope and requirements may be adjusted as the project progresses. In the event that there is a need to adjust the scope and requirements, coordination with the project sponsor will occur prior to implementation of the adjustments. Timothy Maloney Approved by: 2/21/17 Timothy Maloney, Project Sponsor Date 10