CS495notes/Day 6 (problem domain entities)/CampusVisits.md

Campus visits

Overview

In the Math and CS Department, the current workflow for campus visits works as follows.

1. The department secretary receives a campus visit request from the campus visit office.
2. The secretary sends an email to the computer science professors asking if someone could take the visit. Information pertaining to the visit is included in this email (prospective student's name, anticipated major, hometown, date of visit, and possible times that could be scheduled that day).
3. Professors email back saying that they can take the visit (or not) and at what time.

The main problem is with the last step. Professors will often delay in responding, for a variety of reasons. For example:

• A professor might be technically available for a certain day, but it would be hectic to fit it in so they would rather someone else take that one.
• Professors might delay in responding, reasoning that if they delay then someone else will take it.
• A professor might not be able to take the visit, but won't actually respond saying so.

This results in the secretary having to send multiple emails asking for someone to take the visit, and/or the CS chair polling the secretary to see if a visit is taken yet. When an incoming student doesn't know if they will be meeting with a professor it sets a bad impression, especially for those who travel great distances for the campus visit.

System expectations

We would like a system to address the following:

• There should be some way of encouraging a balance between the number of visits assigned to various professors (perhaps there should be a record of number of visits taken, etc.)
• We expect a quick turnaround time, so that the student has confirmation of which professor they are meeting with in, say, within a few days of the visit info coming to the department secretary.
• The system should eliminate the need for the secretary to nag and for the CS chair to keep polling to see if visits are taken or not.
• Address the "social loafing" problem by managing better communication between the professors (for example, some quick and convenient way of expressing "I can do this visit if nobody else is available, but I would rather not"). The system may take this information into account when sending auto-notifications to the faculty.

Entities

• Users
  • Role: boolean for each of: (coordinator, admin, tour guide)
  • Busy times (for guides)
• Visits
  • Possible times (start and end intervals)
  • Visitors
  • Where
  • Decided time (start/end)
  • Decided guide (if any)
  • Status (proposed, assigned, completed, cancelled, conflicting)
• Visitors
  • Role (prospective student, parent, etc.)
  • Antipicated start semester
  • Antipicated majors, minors
• Existing campus visit system to sync with?

Events