CSC/ECE 517 Spring 2022 - E2245: View for results of bidding

CSC/ECE 517 Spring 2022 - E2245: View for results of bidding

Problem Statement

When topics are opened up for bidding, students can see how “hot” each topic is by the color it has on their topic list. However, instructors have no way to view the bidding process except by impersonating students. Furthermore, when the bidding assignment algorithm is run, there is no way to verify that it did in fact assign teams to topics they had chosen. This project is to create a field for instructors on the topic list that shows how many teams have bid for each project. Depending on how you implement it, you might or might not set up the topics to change color. Since topic lines in the topic list potentially have several fields, including partner advertisements, take care that (1) the #-of-bids field is not displayed except for projects that use bidding for topics, and (2) the field is as narrow as feasible. Also, there should be a way to see how many teams have made each topic their #1 bid, #2 bid, etc. And for any team, there should be a way to show all of its bids. There should still be a way to see the bids after the bidding-assignment algorithm has been run, so that it can be checked to see if it did a reasonable job of assigning teams to topics. I do not want to tell you how to organize the display, but please give it some thought and discuss it with me, so that we can come up with a highly usable interface

Project Goal

Develop a trigger that:

1. Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity
   
   • ex. max members = 4, trigger activated when the team size reaches 3
2. Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.
3. Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
4. Possibly notify the team members that they have been assigned the mentor with contact information.

Previous Work

Design Pattern

Since the trigger they implemented would need multiple handlers and each of the responses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioural design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain. The reason to take this approach is we have a certain question which needs to be answered, based on the answer the flow moves. It follows a sequence which follows this behaviour pattern well.

Improvement on the Previous Work

Change in Work Flow Diagram

Controllers:

• app/controllers/submission_records_controller.rb

Models:

• app/models/assignment_team.rb

Views:

• app/views/student_task/view

Rspec:

• spec/features/staggered_deadline_spec.rb

I. Refactor Code to follow good coding practices
Example:
1. Rename method names more meaningfully and intuitive. 2. Reduce the number of conditional statements checking for mentor. 3. Rename variable names to reduce confusion like changing lowest_team_no to lowest_number_of_teams. 4. Make the code DRYer

II. Correct Previous Design

1. Remove mentors from being included in a team's number of members count.

2. Change the View to make mentor separate from the team.
BEFORE

AFTER

3. Change the conditional statement that checks if a mentor has to be added to the team. (The strength of the team has to be greater than 50% of the team size).

4. Fix the SUBMIT button issue during role selection

III. Code placed in the wrong locations to be moved to the desired locations.
Example:

1. The email code moved to the email module.
2. Code written in team file moved to the assignment team file.

Functionalities added

• The mentor should be able to check submissions of his team.
  

This is a new functionality, where a mentor when logged in , would be able to view all the teams assigned under him for an assignment, when he clicks view and manage teams. Additionally the respective teams submissions and submission histories could be viewed by the mentor (if and only a submission is available).Existing functions and classes were reused.

Testing

1. Some existing test cases have been modified, which have been reverted.
   
2. Run and pass the existing RSpec Tests.
   
3. Test the UI for the deployed project.
   

UI Testing

Part 1:

• Login as the instructor6
  

Part 2:

• Login as student575 (added to the program by the instructor)
  

Future Work

• If a mentor is removed from an assignment, reassignment of mentor has to be done. (edge-case)
• Rspec for email functionality needs to be implemented.

Team Roster

• Duy Nguyen - dvnguye3@ncsu.edu
  
• Kwon HyeokJun - khyeokj@ncsu.edu
  
• Shawn S - ssaleki@ncsu.edu
  
• David Glymph - dwglymph@ncsu.edu
  

Mentor: Ed Gehringer - efg@ncsu.edu

Reference

Previous Work