CSC/ECE 517 Spring 2016 E1676 Role-based reviewing: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(Created page with "== Purpose == When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, ...")
 
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Purpose ==
== Task Description==


When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.


*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
== Purpose  ==
*There are occasions when it's advantageous to review projects as a team .
*It helps foster discussion and thereby improves the process of learning.


== Task Description ==
===Rationale of using Scrum & Role based reviewing ===
This project comprises of the following steps :
 
# Objects of ResponseMap record the information of who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review. # We added a boolean field "reviewer_is_team" to identify if the review is being performed by a team or an individual.
# The review strategy is assignment specific and hence we have added a field reviewer_is_team to the assignments table as well
# For an Instructor to specify whether the review is a Team/Individual based review, we have provided a dropdown on the Review Strategy tab of assignment creation.
# If reviewer_is_team field is true the reviewer_id in the response_map is set to the corresponding team_id of the user
# Ensure that features such as "view my scores", or the "alternate view/heat map" continued working.


== Design ==
== Design ==


==== Design Pattern ====
=== UML Diagram ===
'''Model View Controller'''
=== Design Pattern ===
 
In an MVC model, a software application is divided into three major components: Model, View and Controller.
 
'''Model''' - Keeps data, logic and relations between objects and the database. It also handles validations, associations and transactions.
 
'''View''' - Displays the data received from the controller in the user interface.
 
'''Controller''' - Accepts the client's input and converts it into action points for the model or view. Other responsibilities include querying models and organizing data in a structure that is displayed by the view.
 
==== Use Case Diagram ====
 
 
'''Name:''' Specify review type on Review Strategy tab.
 
'''Actor:''' Instructor.
 
'''Description:''' The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.
 
 
 
'''Name:''' Perform Review.
 
'''Actor:''' Individual Student/Team.
 
'''Description:''' The individual/team will perform a review for the Assignment.
 
[[File:OODDUseCase.jpg]]
 
=== Database Design ===
=== Database Design ===


1. The below fields have been modified in the response_maps table:
==Updates==


{| class="wikitable"
Below are the key files to be modified:
|-
===Controllers===
! Field
! Data type
|-
| reviewer_id
| int(11)
|-
| reviewer_is_team
| boolean
|}


The description of the fields of the database for ResponseMap:
===Models===


i. '''reviewer_id:''' Based on the reviewer_is_team flag in the assignments table , the assignment team or the participant id is added in this column.


ii. '''reviewer_is_team:''' If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.
===Views===


== Testing Details ==
In our project, we are providing an option of adding duty for different team members in an assignment and giving review options based on their duty. We will add following functionalities:
1. How instructor create assignment with duties/roles
2. How students take duties from a given list of duties
3. How teammate evaluation rubric assign different review questionnaire based on duty.


=== UI Testing ===
UI will be tested manually. First, we will test creating an assignment as an instructor with different duties and assign different review questionnaires to each duty. Then we will login in as a student and take a duty from given list of duties. We will try covering all edge case scenarios in test cases section.


2. The below fields have been modified in the assignments table:  
=== Test Cases ===
Following will be the test cases:


{| class="wikitable"
1. Login in as an Instructor:
|-
! Field
! Data type
|-
| reviewer_is_team
| boolean
|}


1. '''reviewer_is_team:''' - This field is set based on the discretion of the instructor who decides if the assignment is a to be reviewed individually or as a team.
  1.a] While creating an assignment, in the Review Strategy tab provide the list of roles/duties possible for teammates. There will be one text box to add     
      duty. To add more duties click on "add more".
  1.b] Mark the check box that says multiple team members can have the same duty.
  1.c] Go to the Rubrics tab and select different questionnaires for different duty.   
  After creating this assignment students should be able to see different duties in "Your Team" page and should be able to select any duty. Multiple students
  should be able to select same duty.


==Implementation==
2. Login in as an Instructor:


Below are the key files modified:
  2.a] Repeat steps 1.a and 1.b
====Controllers====
  2.b] This time do not mark the check box that says "multiple team members can have the same duty".
  After creating this assignment students should be able to see different duties in "Your Team" page. This time student should not be able to select a duty if
  it was already selected.


* '''review_mapping_controller.rb:'''
3. Login in as a Student


1. We have added a check in the assign_reviewer_dynamically method that checks if the assignment is a team_reviewed assignment to fetch the respective row from the participants or the teams_users table
  When you login in as a student you should be able to pick different duties assigned by the instructor. If multiple members are not allowed to have same duty
  then you should not be able to pick a duty if it was already selected by some other member.


[[File: review_mapping_controller1.jpg]]
4. Login in as a Reviewer


  When you login in as a reviewer you should get the questionnaire based on your duty. For example, if you are a software engineer you should get the review
  questionnaire assigned to software engineer.
  Different roles will be assigned different questionnaires for review.


2. Also while redirecting to the student_review controller the participant_id or the team_id is passed based on the type of review
=== RSpec ===
 
[[File: review_mapping_controller2.jpg]]
 
 
* '''response_controller:'''
 
1. Below is the get_reviewer_from_response_map method that returns the team or participant id based on the type of review . Also this value is passed forward to the respective controller we redirect to. The get_participant method returns the row from the participants table corresponding to the current user.
 
[[File: response_controller1.jpg]]
 
 
[[File: response_controller2.jpg]]
 
 
* '''student_review_controller:'''
 
1. Same logic as applied in the review mapping controller to obtain the reviewer.
 
[[File: student_review_controller1.jpg]]
 
====Models====
* '''assignment_team.rb:'''
 
1. A row is being created in the response_maps table depending on if it's a team or individual review. The same logic is being applied to check and retrieve the appropriate row form the response map.
 
[[File: assignment_team_model.jpg]]
 
 
* '''assignment.rb:'''
 
1. The logic to not allow reviewers to review their own work has been modified to include scenarios when it's a team based review.
 
[[File: assignment_model.jpg]]


====Views====
For functional testing, we will use RSpec. It uses Behavior Driven Development (BDD) for testing functionality of the system. It provides way to describe specific functionality of the system being tested and helps in better visualization of test cases.
* '''assignments/edit/_review_report.html.erb:


1. Added the below drop down so that the instructor can select the review strategy for the assignment.
=== Capybara ===
 
We will use Capybara  for automating the manual test cases. It is a web-based automation framework and coupled with RSpec. It allow developers to write the test cases which simulate the whole scenario of manual testing.
[[File: drop_down.jpg]]
 
== Testing Details ==
 
=== RSpec ===
RSpec is a testing framework for Rails, and is a Behavioral-Driven Development tool. It is a domain specific language(DSL). All the tests can be executed by rspec spec command, or can also be executed individually using the command "rspec spec/models/assignment_team_spec.rb".
 
We intend to write unit tests using RSpec for all the methods which we modified/created.


===Factory Girl===
===Factory Girl===
Factory Girl is used for creating Assignment and Team objects to be used for testing. Factory Girl is a replacement for fixtures. Fixtures have to be updated whenever we change a data model whereas adding and removing fields is much easier in Factory Girl. Fixture definitions are global whereas Factories can be local, so isolated cases can be tested. Factories are defined to create objects for testing.
We will use Factory Girl for creating data factory. Factory Girl is a Ruby Gem that allow users to create templates for valid and re-usable objects. It allows more customization when user instantiate the objects and it aims to ensure that user have a valid object to work with.
 
===Running RSpec===
<code>
  $ rspec spec/models/assignment_team_spec.rb
</code>
===Test Cases===
1. If the instructor selects "Review by team", check if the review is done by a team member, not by participant.


2. If one teammate is working on a review, another teammate should not be able to edit it at the same time.
== References ==

Latest revision as of 06:09, 9 November 2016

Task Description

Purpose

Rationale of using Scrum & Role based reviewing

Design

UML Diagram

Design Pattern

Database Design

Updates

Below are the key files to be modified:

Controllers

Models

Views

Testing Details

In our project, we are providing an option of adding duty for different team members in an assignment and giving review options based on their duty. We will add following functionalities: 1. How instructor create assignment with duties/roles 2. How students take duties from a given list of duties 3. How teammate evaluation rubric assign different review questionnaire based on duty.

UI Testing

UI will be tested manually. First, we will test creating an assignment as an instructor with different duties and assign different review questionnaires to each duty. Then we will login in as a student and take a duty from given list of duties. We will try covering all edge case scenarios in test cases section.

Test Cases

Following will be the test cases:

1. Login in as an Instructor: 

 1.a] While creating an assignment, in the Review Strategy tab provide the list of roles/duties possible for teammates. There will be one text box to add      
      duty. To add more duties click on "add more". 
 1.b] Mark the check box that says multiple team members can have the same duty.
 1.c] Go to the Rubrics tab and select different questionnaires for different duty.    
 After creating this assignment students should be able to see different duties in "Your Team" page and should be able to select any duty. Multiple students 
 should be able to select same duty.

2. Login in as an Instructor: 

 2.a] Repeat steps 1.a and 1.b 
 2.b] This time do not mark the check box that says "multiple team members can have the same duty".
 After creating this assignment students should be able to see different duties in "Your Team" page. This time student should not be able to select a duty if 
 it was already selected.

3. Login in as a Student 

  When you login in as a student you should be able to pick different duties assigned by the instructor. If multiple members are not allowed to have same duty 
  then you should not be able to pick a duty if it was already selected by some other member.

4. Login in as a Reviewer 

  When you login in as a reviewer you should get the questionnaire based on your duty. For example, if you are a software engineer you should get the review 
  questionnaire assigned to software engineer. 
  Different roles will be assigned different questionnaires for review.

RSpec

For functional testing, we will use RSpec. It uses Behavior Driven Development (BDD) for testing functionality of the system. It provides way to describe specific functionality of the system being tested and helps in better visualization of test cases.

Capybara

We will use Capybara for automating the manual test cases. It is a web-based automation framework and coupled with RSpec. It allow developers to write the test cases which simulate the whole scenario of manual testing.

Factory Girl

We will use Factory Girl for creating data factory. Factory Girl is a Ruby Gem that allow users to create templates for valid and re-usable objects. It allows more customization when user instantiate the objects and it aims to ensure that user have a valid object to work with.

References

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_E1676_Role-based_reviewing&oldid=104904"