Magister’s Team Website
Table of Contents
Teaching Assistant Scheduling and Management System
Team Members
- Andrew Liddell - ajl496@nau.edu
- Joe Domabyl V - jwd98@nau.edu
- Daniel Drake - dcd97@nau.edu
- Junjian Yin - jy358@nau.edu
Project Sponsor
Dr. Viacheslav Fofanov - Associate director of the graduate program for SICCS at NAU
Email: Viacheslav.Fofanov@nau.edu
Technical Advisor
Volodymyr Saruta
Email: vvs28@nau.edu
Meet the Team!
Roles
- Joe Domabyl V
- Team Leader
- Release Manager
- Lead Architect
- Daniel Drake
- Editor
- Presentation Coordinator
- Andrew Liddell
- Website Developer
- Editor
- Meetings Recorder
- Junjian Yin
- Lead designer
- Client Relations Manager
What is this project for?
The responsibility of the associate director of the SICCS program is nothing short of massive. Scheduling classes and placing qualified TA’s in their respective classes is tedious and monotnous, but very consuming of what little time they have. As of now, they must manually assign TA’s in an excel spreadsheet. This is a terrible setup due to the following circumstances:
- A TA requesting a schedule change
- A TA being terminated
- Having to account for everyone’s classes
- Having to organize semesters
- TA’s not being qualified enough to teach certain classes
When either of these circumstances occur, a butterfly effect of holes also open up, which means many people must be moved around to fill that hole. Doing this process manually with a spreadsheet is terrible, hence the heart of our problem. The goal is to develop a web application that can organize TA’s depending on their qualifications and automatically sort out any holes left if a TA makes a change or is terminated. As a stretch goal, we also want a system that allows TA’s to non-confrontationally ask if they could swap with other TA’s if they desire their spot.
Dr. Fofanov has a personal stake in this project, in that he wishes to quell the tedium of this task through a web application developed by us! If we can develop a great web application to handle this issue, we will try to expand our horizons to the rest of the department, or maybe even to other departments and universities. The impact of such could be huge.
The original document of what Fofanov had in mind can be found here:
Original Capstone Proposal |
Here is our promotional intro video for the product!
Sales Pitch Video |
Development Requirements/Process
Requirements Overview
We have developed a series of requirements to solve this problem and design a high quality web application:
- A stable web hosting service with a preconfigured instance to host Django
- A database that will keep track of all assigned alumni (including their info) for each semester.
- A django environment encapsulating all of the database information and rendering it to the end-user in the form of templated html pages.
- An efficient optimization algorithm that automatically organizes TA assignment depending on which moving decisions are made.
- A way to send our own links of admission so that the TA’s can create their own account on the system.
Data Management System
The database will be common ground for both the TA and the Lab-organizer type users. Upon login, the user will either be directed to the lab organizer page or the TA page depending on their credentials. Only the lab organizer will be able to make changes to the database, while both types of users will be able to see from the database. The TA will see the entries for their own schedule while the lab organizer will have all access to the information about the TA’s. In order to get the information in the first place, the lab organizer can recruit TA’s and ask for information via emails and forms. This is labeled via the diagram below.
Web GUI
The application will feature a GUI that will allow users to visualize TA scheduling as well as employ a set of buttons that provide a series of different functions. Both user account-types will be presented with a different version of the GUI upon login. Each user will be shown pages based on the work they are trying to accomplish. Below is a rouch sketch of what the GUI should look like.
Diagram of the Lab Coordinator Interface
Diagram of the TA Interface
User-Based Authentication and Permissions
Users of the application will first be authenticated by the system and subsequently given different permissions based on their account status. The importance of strict roles and permissions are to ensure security, confidentiality, and to ensure the equal satisfaction of all TA’s that are scheduled. The application will complete most of the scheduling work for the lab organizer while also allowing the organizer to make any changes necessary to fit the current context. The TA’s will not have any direct permissions in terms of schedule changes, but will be allowed to see their entire schedule.
Optimization Algorithm
The application will provide a way of organizing and placing TA’s into their qualified positions. In the backend of the system will be an optimization algorithm that will contextually decide which TA gets assigned to which lab. This algorithm will contain a generalized formula for scheduling TA’s using a number-based scoring system. All TA’s hired for a specific semester will be evaluated through each semester and assigned a score based on their skill qualification. The TA with the highest score for a certain lab will be assigned to that lab.
Account Configuration and Setup
There will be two primary aspects of account configuration and setup. First, the lab organizer will be able to create an account for themselves to be able to moderate their labs. Second, each TA will be able to access the application in order to provide their personal data, allowing them to be scheduled within the system. Upon email recruitment via the lab organizer, the TA will be invited to the website and be prompted to enter their relevant information so that they could be scheduled appropriately by the algorithm.
Development Process Overview
The team standards for our development process can be found here:
Team Standards |
As of now, the team has completed six documents relevant to the big milestones in our web application. They can be viewed with the following links:
Teach Feasibility |
Requirements Document |
Communication Strategy Memo |
Software Design Plan |
Software Testing Plan |
Alpha Demo Flight Plan |
Here, you can find all of our design review presentation slides, along with our video presentation of Design Review 2!
Design Review 1 |
Design Review 2 |
Design Review 3 |
Design Review 2 Presentation Video |
Technologies
Django
Django is a highly scalable web framework that will allow us to make great looking and dynamic web pages that allow the user to quickly navagate and use the appropriate tools for the website. The main focus of using this framework is to develop a template of html pages and use the built-in sys admin component for the use of Fofanov.
JQuery
This library will allow us to make nice asynchronous webpage updates to our application, specifically in regards to generating switch possibilities to the lab organizer.
General text editors
For the most part, we do not plan to use many IDE’s for the design of this project. Editors like vim, emacs, etc. will be own main tools for development.
Bitnami
Bitnami will be the preconfigured deployment environment for QuickSched. The application will be designed to fit upon and nicely install in this instance.
AWS - Lightsail
We will be using this web hosting service for our entire application. The servers will be trustworthy and efficient, and the budget will be very low considering the smaller scale of this project. Lightsail offers a reliable hosting service that we need, along with phenominal support for django deployment.
Github
Our code repository of choice will be github. Since many of the team members have plenty of experience with it, we will use it for our version control for the project.
Envisioned Solution
This application will allow a lab organizer to place the TA’s in a table initially, but the algorithm gets the job done depending on how the TA’s recorded their proficiencies on the google form. Faculty will have read only privileges and will be able to make requests for changes in the database. This must be modifiable enough so that restraints when making changes to the database can be modified. If there is a schedule conflict for one of the TA’s there will be a large pentalty from being assigned to said course, as the optimiser will be less likely to assign the student.
The lab organizer will be given a completely different view than a TA or GTA accessing the website. The lab organizer will be able to make schedule changes, see possible schedules, and view the history of changes made by them. The envisioned solution we have is all parts in terms of TA and evaluation will be automated, while the lab organizer can make as many ammendments as they want. The process for changing any fields, weights or constraints should be simple and easy.
The TA and GTA will only be allowed to see the schedule and where they are assigned. As a stretch goal, they will be allowed to request a sawp with another TA with the lab organizer’s approval.
Our presentation with the proposed solution can be found here:
Mini Intro |
Our Schedule and Resources
We are extremely early in the development process, so currently we are researching our options to build this application the best way possible. We will soon upload our technological feasibility document to show the current process.
[week] | Sunday | Monday | Tuesday | Wedensday | Thursday | Friday | Saturday |
---|---|---|---|---|---|---|---|
8/23 | |||||||
8/30 | |||||||
9/6 | |||||||
9/13 | |||||||
9/20 | |||||||
9/27 | Team Standards and Inventory Due | ||||||
10/4 | Begin individual research on feasible technologies | ||||||
10/11 | Inegrate research to our Tech feasibility document | Meet with Dr. Fofanov to discuss tech | |||||
10/18 | Begin prototyping our solution with django environment and redis database | Complete Tech feasibility document | |||||
Integrate planning for implementing our application in reqirements doc | |||||||
10/25 | |||||||
11/1 | |||||||
11/8 | |||||||
11/15 | Present Design Review Number 1 | ||||||
11/22 | Finish sketch for web GUI | ||||||
11/29 | Finish Redis Database and Django integration | Sign requirements contract with Dr. Fofanov | |||||
12/6 | Finish optimization algorithm prototype |
[week] | Sunday | Monday | Tuesday | Wedensday | Thursday | Friday | Saturday |
---|---|---|---|---|---|---|---|
1/10 | |||||||
1/17 | Begin sprint to code our application | Finish Communications Memo | |||||
1/24 | Meet with Dr. Fofanov to check GUI progress | ||||||
1/31 | Finish Software Design Document | ||||||
2/7 | Finish UGRADS Registration | ||||||
2/14 | Team Standards and Inventory Due | ||||||
2/21 | Final Touches to Design Review 2 | Show Design Review 2 to Mentor | |||||
2/28 | Finish Flight Plan Demo | Finish Touches on Alpha Application | |||||
3/7 | Alpha Demo With mentor | Alpha Demo with Client | |||||
3/14 | |||||||
3/21 | |||||||
3/28 | Testing of prototype | Bug testing with client | |||||
4/4 | Finish Design Review 3 | Present Design Review 3 | |||||
4/11 | Prepare UGRADS Presentation | ||||||
4/18 | Presentation Dry Run with Mentor | Present Application at UGRADS | |||||
4/25 | Design Final Product Report | ||||||
5/2 | Show Final Product to Mentor |
Codebase
Here is the current github repo for our Django environment. As of now, we have reached the alpha stage in our development of quicksched. The repo for which can be found via the link, or the archived file blow it.
https://github.com/joedomabylv/taschman |
QuickSched.zip |
Live Demo of QuickSched
The unlisted youtube link gives a brief walkthrough of how the lab organizer will organize their TA’s
https://www.youtube.com/watch?v=GonE5y21-mQ |