CSC/ECE 517 Fall 2014/final E1475 nrnn

Problem Statement

According to the existing code workflow, the assignment of topics to teams are based on first come first serve basis, where a team which first signs up for a topic gets the topic while the other teams which choose the same topic are waitlisted. Since ‘sign up time’ is the only factor considered for topic assignment this method causes problems such as:

1. Non-uniform distribution of topic between teams in a class
2. The current system fails to resolve the problem when many teams bid for handful of topics(among many topics) causing unnecessary additions to the waitlist
3. The assignment of topics is more focussed on individual selection and ‘sign up time’. Factors such as team size are not considered which are important while assigning a topic to the team and potentially can reduce many issues faced by the current system.

To address the above mentioned issues, we have designed an ‘intelligent assignment of topics’ system which tries to address the issues faced by the current system.

Introduction

The signup process for group projects is observed by most students to be a troublesome task in expertiza. The current sign up process for topics is based on FCFS basis, where a student who signs up for a topic of his/her choice first, gets it. We have discovered some pitfalls with the current ‘topic assignment’ system in Expertiza which arises due to the below mentioned factors. Due to these reasons, we now try to propose an intelligent system which can addresses many issues faced with the current Expertiza system.

Pitfalls with the current system

1. One student can sign up only for a single topic. In cases where many topics are available, a student is forced to choose a single topic among many available topics which can be a difficult task. To select a single topic which best fits his/her choice among many available topics requires a pre-study of all topics prior to the signup process. Such a pre-requirement is not fulfilled by most students, which results in a student signing up for a topic which he/she has randomly selected OR because it was among the only available topics.
2. If a student is not able to sign up for a topic of his choice, he can waitlist himself for all the remaining topics, which causes unnecessary traffic in the waitlist queue of a topic.
3. If all the teams choose a handful of topics among many topics, it would also result in unnecessary additions in the waitlist queue for those few topics resulting in a situation where all the topics are not uniformly distributed among all the teams
4. Before, signing up, if more than one student forms a team and if each student belonging to the same team tries to signup for different topics, than those topics are allotted to individual students resulting in a situation where a team can hold more than one topic. Thus other teams are forced to choose from remaining topics which eventually results in longer waitlists.

After observing the above problems with the existing method of ‘topic assignment’ in expertiza, we have proposed and implemented an ‘intelligent assignment of topics’ method to overcome all the shortcomings of the existing system in expertiza.

Previous work

Previously in 2012, to address this issue of expertiza, a team proposed a possible solution of ‘lottery based topic assignment’ algorithm. The algorithm works by considering every team as strength of 1, representing the student in the team. After sign up the topic would be allotted to the team based on a lottery system where a team is randomly selected for every topic. However this method failed to address the following issues:

1. It did not consider the case where a team could be of more than one member, hence it allowed every team member to bid for different topics resulting in the same problem as mentioned in point (4) of Pitfalls with the current system.
2. The topics were awarded based on a Lottery system and not based on any other criteria which resulted in topic assignment to be a game of luck factor rather than on individual’s choice.

Requirements

1) The instructor should be able to create assignments which can utilize intelligent assignment of teams. (It is an optional feature)

2) The instructor should be able to set the maximum number of bids a team can make. Defaulted to 3.

3) The teams should be able place bids on different topics limited to the number set by the instructor for these assignments

4) The teams should be able to prioritize their bids.

5) The instructor should be able to kick off the intelligent assignment of teams.

Sequence Diagram

Fig 1. Sequence Diagram

Fig 1. shows the sequence diagram for this feature. The diagram shows the sequences exclusive to this feature. Therefore, this assumes that the assignment/exercise has already been created. Once the assignment is created, the instructor can enable the 'intelligent assignment of teams' feature for the particular assignment. Enabling this feature would give the students(or teams) a view to place bids on the topics they like. They can associate each bid with a priority. Once the deadline has passed, the instructor can kickoff the process which performs the automatic assignment. This would in turn start assigning teams with topics based on their bid preferences.

UML Design

UML Design

Database Design

In order to meet other solution requirement, new tables are added. The following diagram represents the new tables in crow foot's notation. The user table mentioned is not new and is present only to explain the field - ownerId.

Earlier, all the information in AssignmentTopic and AssignmentTopicMetadata tables were in a single table called signup_topics. However, there was lot of data redundancy observed and we also required to add an extra field in the table signup_topics. Therefore, we decided to store the topics related to an assignment according to the diagram. One caveat to this design is that all the topics for an assignment are considered equal in terms of category, maximum bids allowed and maximum bids in waiting list.

The table bid is supposed to store all the bids on the topics with their priority. The owner of the bid will be recorded too. Current requirement is to have only one bid per topic by an owner. Therefore, we could have (ownerId, topicId) pair as the primary key. However, in order to support multiple bids in a future sceario, we have used a field id as the primary key.

Apart from the mentioned new tables, we will be using pre-existing tables to meet our requirements and design.

Database Design

References

<references/>