Some User
1 year ago
parent
1e1f1a0dd7
commit
2e013b436c
@ -1,61 +0,0 @@
|
||||
|
||||
# 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.
|
||||
1. 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).
|
||||
1. 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
|
||||
- *Coordinator* (boolean) - true iff the user coordinates between CV office and faculty.
|
||||
- *Admin* (boolean) - true for superuser priviledges, such as creating and deleting users.
|
||||
- *Guide* (boolean) - true iff the user can do campus visits for Computer Science.
|
||||
- *Unavailable times* - (for guides only) a weekly schedule of regularly unavailable times for campus visits
|
||||
- Visits
|
||||
- *Visitors* - a list of people in the visiting group
|
||||
- *Possible times* - a list of time intervals in which the visitors are available on the visit day
|
||||
- *Day* - a calendar day for which the visit has been scheduled of the campus visit office
|
||||
- *Decided time* - a time at which the guide has agreed to meet for this visit
|
||||
- *Decided guide* - the guide which has agreed to conduct this visit
|
||||
- *Status* - the current status of this visit:
|
||||
- *Proposed* - created by the CV office, but no guide assigned
|
||||
- *assigned* - a guide has agreed to do the visit, at a decided time
|
||||
- *completed* - the guide has conducted the visit
|
||||
- *cancelled* - the visit has been cancelled before it could be conducted
|
||||
- Visitors
|
||||
- *Role* - the type of visitor: prospective student, parent, or guest (other).
|
||||
- *Antipicated start semester* - the start semester, as reported by the CV office
|
||||
- *Antipicated majors, minors* - desired major(s) and minor(s), from the CV office
|
||||
- *Type* - category (for prospective students only): high school, transfer, or non-traditional
|
||||
- *Hometown* - name of city and state of origin
|
||||
- *Notes* - other information pertaining to the visit that should be made known to its guide
|
||||
- Committment - the level of committment expressed by a given guide for a given visit
|
||||
- *Level* - possible values for involvement are: unknown, cannot, prefer not, can do, will do
|
||||
|
||||
|
||||
|
||||
## Events
|
||||
|
||||
|
||||
|
||||
TODO: Have conflicts reported by the system if detected.
|
||||
|
Before Width: | Height: | Size: 26 KiB |
@ -0,0 +1,134 @@
|
||||
|
||||
# Campus visits
|
||||
|
||||
Prepared by: Michael Kowalczyk
|
||||
Revision date: 9/10/2024
|
||||
|
||||
## 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.
|
||||
1. 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).
|
||||
1. 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
|
||||
|
||||
- User
|
||||
- *Name* - person's name
|
||||
- *Email* - email address used for login and notifications
|
||||
- *Password* - for logging into the web portal
|
||||
- *Roles* - zero or more of these options: coordinator, admin, or faculty.
|
||||
- *coordinator* - communicates with the CV office and communicates with faculty to determine who is doing a visit
|
||||
- *Admin* - has superuser priviledges, such as creating and deleting users.
|
||||
- *Faculty* - a user who can do campus visits for Computer Science.
|
||||
- *Available times* - (for faculty only) a weekly schedule of regularly available times for campus visits
|
||||
- Visit
|
||||
- *Visitors* - a list of people in the visiting group
|
||||
- *Possible times* - a list of time intervals in which the visitors are available on the visit day
|
||||
- *Day* - the calendar day for which the visit has been scheduled with the campus visit office
|
||||
- *DecidedTime* - the time at which the faculty member has agreed to meet for this visit
|
||||
- *DecidedGuide* - the faculty member who has agreed to conduct this visit
|
||||
- *Status* - the current status of this visit:
|
||||
- *proposed* - the visit is known to the department, but no faculty is assigned
|
||||
- *assigned* - a faculty member has agreed to do the visit at a *decided time*
|
||||
- *confirmed* - the secretary has informed the Campus Visit office of the *decidedGuide* and *decidedTime*
|
||||
- *completed* - the *decidedGuide* has conducted the visit
|
||||
- *canceled* - the visit has been canceled before it could be conducted
|
||||
- *Notes* - other information pertaining to the visit that would be useful to the *decidedGuide*
|
||||
- Visitor
|
||||
- *Name* - actual name
|
||||
- *Role* - the type of visitor: prospective student, parent, or guest (other).
|
||||
- *Antipicated start semester* - the start semester, as reported by the CV office
|
||||
- *Antipicated majors, minors* - desired major(s) and minor(s), from the CV office
|
||||
- *Type* - category (for prospective students only): high school, transfer, or non-traditional
|
||||
- *Hometown* - name of city and state of origin
|
||||
- Committment - the level of committment associated with a given faculty member for a particular visit
|
||||
- *Level* - possible values for involvement are: unknown, cannot, prefer not, can do
|
||||
|
||||
|
||||
|
||||
## Queries
|
||||
|
||||
These queries can be performed by any user.
|
||||
|
||||
- **Q1** - List visits. *Parameters: startDate, endDate, assignedFaculty, currentStatus* (any or all of these can be omitted, and assignedFaculty may be "none" to search for unassigned visits). *Result:* For each visit matching all of the parameters given: list student name(s), day, possibleTimes, decidedTime, decidedGuide, and status. Sorted by visit day.
|
||||
- **Q2** - View visit. *Parameters: visitID*. View all attributes for the given visit, and also the associated committment level for each faculty member in the system.
|
||||
- **Q3** - View faculty stats. *Parameters: startDate, endDate*. For each faculty *f*, list the number of visits *v* for which *v.decidedGuide = f* and also the number of visits *v* for which *v.decidedGuide = f* and *v.status = completed*. For both of these sums, the visits are restricted to *startDate <= v.day <= endDate*.
|
||||
- **Q4** - List users. *Parameters: none*. This query is available for *admin* and *coordinator* only. For each user *u* in the system, list *u.name, u.roles, u.availableTimes* (if *u.roles* includes *faculty*), and *email*.
|
||||
|
||||
## Events
|
||||
|
||||
There are only a few problem domain events of interest. For each of these a source is listed, which is how this event is made known to the system.
|
||||
- *VisitRequest* - the Campus Visit office contacts the department secretary with information pertaining to a new campus visit. *Parameters*: date, possible times, student name, other visitor names, and majors/minors of interest. *Source:* department secretary keys in the data (coordinator role).
|
||||
- *ClaimVisit* - a faculty member decides to do a visit. *Parameters*: visit, decidedGuide, decidedTime. *Source:* faculty member.
|
||||
- *ConfirmVisit* - the department secretary contacts the Campus Visit office that someone has taken the visit. Parameters: visit's *decidedGuide* and *decided time*. *Source:* department secretary (coordinator role).
|
||||
- *CancelVisit* - the campus visit office notifies the department secretary that the visit has been cancelled by the student. *Parameters:* Visit. *Source:* department secretary (coordinator role).
|
||||
- *AbaondonVisit* - some circumstance has caused the faculty member to vacate the guide position for a visit. *Parameters:* Visit. *Source:* faculty member.
|
||||
- *VisitTimePassed* - the *decidedTime* for the visit plus an hour has passed in Eastern Time.
|
||||
|
||||
|
||||
|
||||
## Notifications
|
||||
|
||||
**R1** - The system notifies faculty via email under any of the following circumstances:
|
||||
- A new *visitRequest* is made
|
||||
- The faculty member is the *decidedGuide* for a visit which is scheduled for tomorrow
|
||||
- Periodic reminders for faculty members who have an unknown committment level for one or more proposted visits.
|
||||
|
||||
**R2** - The system notifies coordinators via email under any of the following circumstances:
|
||||
- Periodic reminders for visits that are in the *proposed* state.
|
||||
- A time conflict has been detected between two different visits.
|
||||
|
||||
**R3** - Both faculty and coordinators are notified if a faculty member has claimed or abandoned a visit (except for a faculty member who changed his own status)
|
||||
|
||||
## Platform
|
||||
**R4** - All users can log into the system as a web app to perform actions suitable to their role(s).
|
||||
|
||||
**R5** - Notifications are delivered via email, with embedded unguessable links so that likely actions pertaining to the notification can be performed in one click without logging in.
|
||||
|
||||
## User permissions
|
||||
Users act in different roles with regard to editing the system's internal model of campus visits.
|
||||
|
||||
Users with the coordinator role can:
|
||||
- **R6** - adjust notification frequency for **R1** and **R2** on a per-visit basis.
|
||||
- **R7** - establish a new visit request.
|
||||
- **R8** - claim a visit, acting on behalf of a faculty member (Note: in this case, the faculty member must still get the visit claim notification).
|
||||
- **R9** - set an *assigned* visit to *confirmed*, and can set a visit to *canceled* at any time.
|
||||
|
||||
Users with the faculty role can:
|
||||
- **R10** - set a level of committment and/or claim visits that are in the *proposed* state. Note that a "*can do*" level of committment is implied when a faculty member is the guide for a given visit.
|
||||
- **R11** - abandon visits for which they are the *decidedGuide*.
|
||||
- **R12** - edit *availableTimes*
|
||||
|
||||
Users with the admin role can:
|
||||
- **R13** - create a new user.
|
||||
- **R14** - change any user's name, email, password, or roles.
|
||||
|
||||
Any user can:
|
||||
- **R15** - change their password.
|
||||
|
||||
## Security
|
||||
- **R16** - The web app portal is password-protected and served over HTTPS, exclusively.
|
||||
- **R17** - Embedded email links pertaining to user actions are long, unguessable strings which expire after a certain number of days (which can be set by an admin). Following an expired link shows an error message.
|
||||
|
||||
## Preferences
|
||||
Unnecessary email should be minimized. Within notification frequency, it would be preferable to have a single email containing notifications for all relevant visits rather than receiving a separate email for each notification.
|
||||
|
||||
## Likely changes
|
||||
Rules guiding notification frequency are likely to change. The coordinator has limited control over this, but experience with the system will help to understand how to best give the coordinator more granular control.
|
||||
|
After Width: | Height: | Size: 26 KiB |
@ -0,0 +1,44 @@
|
||||
'Created with https://www.planttext.com/
|
||||
|
||||
@startuml
|
||||
|
||||
skin rose
|
||||
|
||||
title Entity relationships
|
||||
|
||||
class User {
|
||||
name
|
||||
email
|
||||
password
|
||||
roles
|
||||
availableTimes
|
||||
}
|
||||
|
||||
class Visit {
|
||||
day
|
||||
possibleTimes
|
||||
decidedTime
|
||||
status
|
||||
notes
|
||||
}
|
||||
|
||||
class Visitor {
|
||||
name
|
||||
role
|
||||
startSemester
|
||||
majors
|
||||
minors
|
||||
type
|
||||
hometown
|
||||
}
|
||||
|
||||
class Committment {
|
||||
level
|
||||
}
|
||||
|
||||
Visit " *\n visitors ↓" -- "1..*" Visitor
|
||||
Visit "*\ndecided guide →" -right- "0..1\n← visits" User : " "
|
||||
Visit " 1" -up- "*" Committment
|
||||
User "1" -up- "*" Committment
|
||||
|
||||
@enduml
|
||||
|
After Width: | Height: | Size: 26 KiB |
@ -0,0 +1,27 @@
|
||||
'Created with https://www.planttext.com/
|
||||
|
||||
@startuml
|
||||
|
||||
skin rose
|
||||
|
||||
title Events and visit states
|
||||
|
||||
label start
|
||||
card proposed
|
||||
card assigned
|
||||
card confirmed
|
||||
card completed
|
||||
card canceled
|
||||
|
||||
start -down-> proposed : "visitRequest"
|
||||
proposed -down-> assigned : "claimVisit"
|
||||
assigned -down-> confirmed : "confirmVisit"
|
||||
confirmed -down-> completed : "visitTimePassed"
|
||||
|
||||
proposed --> canceled : "cancelVisit"
|
||||
assigned -left-> canceled : "cancelVisit"
|
||||
confirmed --> canceled : "cancelVisit"
|
||||
|
||||
rectangle "The abandonVisit event takes the state from\neither assigned or confirmed back to proposed"
|
||||
|
||||
@enduml
|
||||
Loading…
Reference in new issue