Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2017 E1734

2017-04-29T02:31:44Z

Dpatel12: /* Test Plan */

=Improve survey functionality=

== Problem Description ==

Expertiza used to have functionality for conducting surveys. However, the existing code is inefficient and needs to be improved. This functionality has rarely been used and so isn't tested very well either. Therefore, there are parts of survey functionality that are broken or are totally unfinished.

So, there are three major problems this project will tackle.

1) Restructure and move around functionality within classes to further streamline the code.

2) Test the existing functionality and catalog what parts work and what do not. As an instance of a broken feature, take survey deployments for example. During initial testing, it is not possible to deploy any kind of survey. There are other features as well that need little fixes to make them work.

3) Fixing the broken features. This involves little bug fixes here and there, as well as finishing the features that are completely unfinished.

== Requirements ==

1) A page to show the distribution of results for all types of questionnaires.

2) Use of inheritance so that survey questionnaire is a subclass of the questionnaire class. Also, course evaluation questionnaire and global survey questionnaire should be subclasses of survey questionnaire.

3) Use response_controller to implement the survey functionality. This should be similar to how other questionnaires like the peer review questionnaire, are implemented.

4) Use the same code to display existing survey responses as to display the responses in peer reviews.

5) For each course or assignment, the admin/instructor should be able to create a survey and have some (or all) of the participants receive the survey. The instructor should have the option to not include some questions from a global survey. The quiz takers can take the global survey and course survey consecutively.

6) An entry in the participants table called a survey_participant record must be added to indicate when a user is assigned to take part in a survey.

7) Tests need to be written for the feature.

Note: Although the requirements document mentions that the existing code needs to be scrapped and rewritten, after discussion with professor it was decided that this is not a strict requirement.

== Types of Surveys ==

There are three kinds of surveys available in the Expertiza application. They are differentiated based on the group of people that can have access to these surveys.

The surveys are as follows:

1) Course Survey:

All the participants in a course can take the course survey.

File: course_evaluation_questionnaire.rb

2) Global Survey:

Any Expertiza user can take the global survey.

File: global_survey_questionnaire.rb

3) Targeted Survey:

The admin can create a survey targeted to a specific group of people.

File: survey_questionnaire.rb

== Class Design ==

=== Existing class structure: ===

[[File:E1734-structure-1.png|frame|center]]

=== Updated class structure: ===

[[File:E1734-structure-2New.jpg|frame|center]]

=== New Class Functionality: ===

==== Questionnaire: ====

Contains the basic information and methods required for posing questions to students or users in general. It is inherited by Classes Quiz, Survey, etc.

We can reuse this class's functionality to create, edit and delete surveys. The functionality for checking if questions have been answered can also be borrowed from this class.

==== Survey: ====

This project will introduce a new class called Survey.

This class will inherit from the Questionnaire class and it will be a superclass for the three different kinds of survey classes.

This class will include the assign_participants() method that can be used by any of the child classes to assign participants for their respective surveys.

This class will also have the statistics_generation functionality to be used to provide statistics for any kind of survey. This is the one that will take care of the requirement for getting the distribution of responses.

==== Global Survey: ====

This class will inherit from class Survey.

This class will be set the display_type for the survey to be global. So, while assigning participants all the users of Expertiza will be able to see this particular survey.

This kind of survey can only be created by admins of the Expertiza system.

==== Course Evaluation: ====

This is also another type of survey and will inherit from class Survey.

Surveys of this type, however, will only be available to the class to which this survey would be assigned. Accordingly, the display_type for it will be set to course.

So assign_participants() will create new survey participants for all users in a particular course.

==== Survey Questionnaire: ====

This class will also inherit from the class Survey. The name used for this class may change after further discussions with the professor.

The existing survey_questionnaire class will be repurposed to be used to create surveys that could be targeted to a group of users or be attached to a questionnaire.

It will allow for an association between an assignment and a questionnaire to be established. Additionally, it maintains the instructor id who will create the association.

A flag for a score outside an acceptable range will also be set. It could also be used to play a part in the total score calculation for the assignment.

== Database Schema ==

There are database tables that are used to track the deployment of the surveys, that are used to help keep track of the participants for each survey and that keep track of all the responses for the surveys we create. We would not be making any or would make only minimal design changes to these tables. Our main task would be to go in and fix things that are not currently operational given what we already have.

To give an idea about these database tables we have included them below.

Table: Survey Deployments

{| class="wikitable"
|-
! Element
! Type
! Attributes
|-
| course_evaluation_id
| Integer
| Limit: 4
|-
| start_date
| Datetime
|
|-
| end_date
| Datetime
|
|-
| num_of_students
| Integer
| Limit: 4
|-
| last_reminder
| Datetime
|
|-
| course_id
| Integer
| Limit: 4, Default: 0, Null: false
|}

Table: Survey Participants

{| class="wikitable"
|-
! Element
! Type
! Attributes
|-
| user_id
| Integer
| Limit: 4
|-
| survey_deployment_id
| Integer
| Limit: 4
|-
|}

Table: Survey Responses

{| class="wikitable"
|-
! Element
! Type
! Attributes
|-
| score
| Integer
| Limit: 4
|-
| comments
| Text
| Limit: 65535
|-
| assignment_id
| Integer
| Limit: 4, Default: 0, Nil: false
|-
| question_id
| Integer
| Limit: 4, Default: 0, Nil: false
|-
| survey_id
| Integer
| Limit: 4, Default: 0, Nil: false
|-
| email
| String
| Limit: 255
|}

====UML Diagram====

[[File:UML600.jpg]]

== Tasks to be performed ==

Given the information at hand, the following list will provide a good summary of the tasks we will have to perform to achieve the goals of this project.

1) Change the hierarchical structure of classes. Make survey the child of questionnaire. Global survey, survey_questionnaire and course evaluation to be subclasses of survey.

2) Creation, editing and deletion of questions, is a functionality that would be inherited into class Survey(which is a kind of questionnaire) and so into all its children surveys, from the Questionnaire class.

3) Add new class Survey and include functionality to assign(which is in the survey_controller currently) to this model.

4) In the new class add functionality to generate statistics.

5) The display_type for each of the subclasses of Survey can be set individually in the post_initialization method.

6) The three kinds of surveys can be assigned to some either an assignment, a course, a student or to all the users of Expertiza depending on their display_type.

7) Use the course evaluation tab on the Expertiza homepage to display any pending surveys instead of just the course evaluation surveys. The course evaluation tab’s functionality is currently broken and needs to be fixed.

8) "Survey deployment" functionality is broken. Need to make survey deployment of all forms of surveys functional. This would include the following tasks:

a) Ability to add new survey deployments.
b) View responses to the deployments.
c) Delete deployments.

9) "Statistic generation for Survey" functionality is broken. From the drop down menu in survey deployments, we can select Statistical tests and that should take the user to a page where depending on the survey chosen the corresponding statistics would be displayed.

== Test Plan ==

Testing tool:

RSpec (For the automated tests)

{| class="wikitable"
|-
! Test #
! Type
! Description
! Steps
|-
|Test case 1:
|Automated
|Test to check whether an instructor can create a survey
|
1. Login to Expertiza as an instructor.

2. Click Manage… and go to Questionnaire.

3. Select new public/private item of the type of survey you want to create.

4. In the Questionnaire view, create the questionnaire by Clicking Create.
|-
|Test case 2:
|Manual
|Test to check whether a survey is deployed to the appropriate users
|
1. After creation of a survey that a particular student can participate in, login as that student.

2. The student can then participate in the survey by clicking on Pending Surveys.

3. If the survey appears there, that indicates that the survey has been deployed successfully.
|-
|Test case 3:
|Automated
|Test to check whether the statistics of survey responses is displayed
|
1. Login to Expertiza as an instructor.

2. Assuming that a survey is created, and students have participated in it, we can check the distribution of results.

3. Click on Survey Deployments in the page header.

4. Click Statistics of a particular survey that was created to view the statistics of responses.
|-
|Test case 4:
|Manual
|Test to check that only allowed users can participate in the survey
|
1. Login to Expertiza as a student that is not included as a participant in the survey.

2. By clicking on Surveys, the list of surveys that the student can currently take is displayed.

3. If the survey that was created is not visible, then the user is correctly excluded.
|-
|Test case 5:
|Automated
|Test to check whether an instructor can view responses of a survey deployment
|
1. Login to Expertiza as an instructor.

2. Assuming that a survey is created, and students have participated in it, the instructor can check the responses to each question.

3. Click on Survey Deployments in the page header.

4. Click View Responses of a particular survey that was created to view the responses.
|-
|}

CSC/ECE 517 Spring 2017 E1734

2017-04-29T02:28:28Z

Dpatel12: Revised the test plan

=Improve survey functionality=

== Problem Description ==

Expertiza used to have functionality for conducting surveys. However, the existing code is inefficient and needs to be improved. This functionality has rarely been used and so isn't tested very well either. Therefore, there are parts of survey functionality that are broken or are totally unfinished.

So, there are three major problems this project will tackle.

1) Restructure and move around functionality within classes to further streamline the code.

2) Test the existing functionality and catalog what parts work and what do not. As an instance of a broken feature, take survey deployments for example. During initial testing, it is not possible to deploy any kind of survey. There are other features as well that need little fixes to make them work.

3) Fixing the broken features. This involves little bug fixes here and there, as well as finishing the features that are completely unfinished.

== Requirements ==

1) A page to show the distribution of results for all types of questionnaires.

2) Use of inheritance so that survey questionnaire is a subclass of the questionnaire class. Also, course evaluation questionnaire and global survey questionnaire should be subclasses of survey questionnaire.

3) Use response_controller to implement the survey functionality. This should be similar to how other questionnaires like the peer review questionnaire, are implemented.

4) Use the same code to display existing survey responses as to display the responses in peer reviews.

5) For each course or assignment, the admin/instructor should be able to create a survey and have some (or all) of the participants receive the survey. The instructor should have the option to not include some questions from a global survey. The quiz takers can take the global survey and course survey consecutively.

6) An entry in the participants table called a survey_participant record must be added to indicate when a user is assigned to take part in a survey.

7) Tests need to be written for the feature.

Note: Although the requirements document mentions that the existing code needs to be scrapped and rewritten, after discussion with professor it was decided that this is not a strict requirement.

== Types of Surveys ==

There are three kinds of surveys available in the Expertiza application. They are differentiated based on the group of people that can have access to these surveys.

The surveys are as follows:

1) Course Survey:

All the participants in a course can take the course survey.

File: course_evaluation_questionnaire.rb

2) Global Survey:

Any Expertiza user can take the global survey.

File: global_survey_questionnaire.rb

3) Targeted Survey:

The admin can create a survey targeted to a specific group of people.

File: survey_questionnaire.rb

== Class Design ==

=== Existing class structure: ===

[[File:E1734-structure-1.png|frame|center]]

=== Updated class structure: ===

[[File:E1734-structure-2New.jpg|frame|center]]

=== New Class Functionality: ===

==== Questionnaire: ====

Contains the basic information and methods required for posing questions to students or users in general. It is inherited by Classes Quiz, Survey, etc.

We can reuse this class's functionality to create, edit and delete surveys. The functionality for checking if questions have been answered can also be borrowed from this class.

==== Survey: ====

This project will introduce a new class called Survey.

This class will inherit from the Questionnaire class and it will be a superclass for the three different kinds of survey classes.

This class will include the assign_participants() method that can be used by any of the child classes to assign participants for their respective surveys.

This class will also have the statistics_generation functionality to be used to provide statistics for any kind of survey. This is the one that will take care of the requirement for getting the distribution of responses.

==== Global Survey: ====

This class will inherit from class Survey.

This class will be set the display_type for the survey to be global. So, while assigning participants all the users of Expertiza will be able to see this particular survey.

This kind of survey can only be created by admins of the Expertiza system.

==== Course Evaluation: ====

This is also another type of survey and will inherit from class Survey.

Surveys of this type, however, will only be available to the class to which this survey would be assigned. Accordingly, the display_type for it will be set to course.

So assign_participants() will create new survey participants for all users in a particular course.

==== Survey Questionnaire: ====

This class will also inherit from the class Survey. The name used for this class may change after further discussions with the professor.

The existing survey_questionnaire class will be repurposed to be used to create surveys that could be targeted to a group of users or be attached to a questionnaire.

It will allow for an association between an assignment and a questionnaire to be established. Additionally, it maintains the instructor id who will create the association.

A flag for a score outside an acceptable range will also be set. It could also be used to play a part in the total score calculation for the assignment.

== Database Schema ==

There are database tables that are used to track the deployment of the surveys, that are used to help keep track of the participants for each survey and that keep track of all the responses for the surveys we create. We would not be making any or would make only minimal design changes to these tables. Our main task would be to go in and fix things that are not currently operational given what we already have.

To give an idea about these database tables we have included them below.

Table: Survey Deployments

{| class="wikitable"
|-
! Element
! Type
! Attributes
|-
| course_evaluation_id
| Integer
| Limit: 4
|-
| start_date
| Datetime
|
|-
| end_date
| Datetime
|
|-
| num_of_students
| Integer
| Limit: 4
|-
| last_reminder
| Datetime
|
|-
| course_id
| Integer
| Limit: 4, Default: 0, Null: false
|}

Table: Survey Participants

{| class="wikitable"
|-
! Element
! Type
! Attributes
|-
| user_id
| Integer
| Limit: 4
|-
| survey_deployment_id
| Integer
| Limit: 4
|-
|}

Table: Survey Responses

{| class="wikitable"
|-
! Element
! Type
! Attributes
|-
| score
| Integer
| Limit: 4
|-
| comments
| Text
| Limit: 65535
|-
| assignment_id
| Integer
| Limit: 4, Default: 0, Nil: false
|-
| question_id
| Integer
| Limit: 4, Default: 0, Nil: false
|-
| survey_id
| Integer
| Limit: 4, Default: 0, Nil: false
|-
| email
| String
| Limit: 255
|}

====UML Diagram====

[[File:UML600.jpg]]

== Tasks to be performed ==

Given the information at hand, the following list will provide a good summary of the tasks we will have to perform to achieve the goals of this project.

1) Change the hierarchical structure of classes. Make survey the child of questionnaire. Global survey, survey_questionnaire and course evaluation to be subclasses of survey.

2) Creation, editing and deletion of questions, is a functionality that would be inherited into class Survey(which is a kind of questionnaire) and so into all its children surveys, from the Questionnaire class.

3) Add new class Survey and include functionality to assign(which is in the survey_controller currently) to this model.

4) In the new class add functionality to generate statistics.

5) The display_type for each of the subclasses of Survey can be set individually in the post_initialization method.

6) The three kinds of surveys can be assigned to some either an assignment, a course, a student or to all the users of Expertiza depending on their display_type.

7) Use the course evaluation tab on the Expertiza homepage to display any pending surveys instead of just the course evaluation surveys. The course evaluation tab’s functionality is currently broken and needs to be fixed.

8) "Survey deployment" functionality is broken. Need to make survey deployment of all forms of surveys functional. This would include the following tasks:

a) Ability to add new survey deployments.
b) View responses to the deployments.
c) Delete deployments.

9) "Statistic generation for Survey" functionality is broken. From the drop down menu in survey deployments, we can select Statistical tests and that should take the user to a page where depending on the survey chosen the corresponding statistics would be displayed.

== Test Plan ==

Testing tool:

RSpec (For the automated tests)

{| class="wikitable"
|-
! Test #
! Type
! Description
! Steps
|-
|Test case 1:
|Automated
|Test to check whether an instructor can create a survey
|
1. Login to Expertiza as an instructor.

2. Click Manage… and go to Questionnaire.

3. Select new public/private item of the type of survey you want to create.

4. In the Questionnaire view, create the questionnaire by Clicking Create.
|-
|Test case 2:
|Manual
|Test to check whether a survey is deployed to the appropriate users
|
1. After creation of a survey that a particular student can participate in, login as that student.

2. The student can then participate in the survey by clicking on Pending Surveys.

3. If the survey appears there, that indicates that the survey has been deployed successfully.
|-
|Test case 3:
|Automated
|Test to check whether the statistics of survey responses is displayed
|
1. Login to Expertiza as an instructor.

2. Assuming that a survey is created, and students have participated in it, we can check the distribution of results.

3. Click on Survey Deployments in the page header.

4. Click Statistics of a particular survey that was created to view the statistics of responses.
|-
|Test case 4:
|Manual
|Test to check that only allowed users can participate in the survey
|
1. Login to Expertiza as a student that is not included as a participant in the survey.

2. By clicking on Surveys, the list of surveys that the student can currently take is displayed.

3. If the survey that was created is not visible, then the user is correctly excluded.
|-
|Test case 5:
|Automated
|Test for the display_type after creation of a survey
|
1. Create any kind of survey, i.e. Survey Questionnaire, Global Survey Questionnaire, or Course Evaluation Questionnaire.

2. Post_initialization, as the name suggests, is called after the initialization of a survey, so it gets called on creation in the first step.

3. Assert whether the value of display_type is course/survey/global depending on what survey was created.
|-
|Test case 6:
|Automated
|Test to check whether an instructor can view responses of a survey deployment
|
1. Login to Expertiza as an instructor.

2. Assuming that a survey is created, and students have participated in it, the instructor can check the responses to each question.

3. Click on Survey Deployments in the page header.

4. Click View Responses of a particular survey that was created to view the responses.
|-
|}

CSC/ECE 517 Spring 2017 E1734

2017-04-13T02:16:16Z

Dpatel12: /* Test Plan */

=Improve survey functionality=

== Problem Description ==

Expertiza used to have functionality for conducting surveys. However, the existing code is inefficient and needs to be improved. This functionality has rarely been used and so isn't tested very well either. Therefore, there are parts of survey functionality that are broken or are totally unfinished.

So, there are three major problems this project will tackle.

1) Restructure and move around functionality within classes to further streamline the code.

2) Test the existing functionality and catalog what parts work and what do not. As an instance of a broken feature, take survey deployments for example. During initial testing, it is not possible to deploy any kind of survey. There are other features as well that need little fixes to make them work.

3) Fixing the broken features. This involves little bug fixes here and there, as well as finishing the features that are completely unfinished.

== Requirements ==

1) A page to show the distribution of results for all types of questionnaires.

2) Use of inheritance so that survey questionnaire is a subclass of the questionnaire class. Also, course evaluation questionnaire and global survey questionnaire should be subclasses of survey questionnaire.

3) Use response_controller to implement the survey functionality. This should be similar to how other questionnaires like the peer review questionnaire, are implemented.

4) Use the same code to display existing survey responses as to display the responses in peer reviews.

5) For each course or assignment, the admin/instructor should be able to create a survey and have some (or all) of the participants receive the survey. The instructor should have the option to not include some questions from a global survey. The quiz takers can take the global survey and course survey consecutively.

6) An entry in the participants table called a survey_participant record must be added to indicate when a user is assigned to take part in a survey.

7) Tests need to be written for the feature.

Note: Although the requirements document mentions that the existing code needs to be scrapped and rewritten, after discussion with professor it was decided that this is not a strict requirement.

== Types of Surveys ==

There are three kinds of surveys available in the Expertiza application. They are differentiated based on the group of people that can have access to these surveys.

The surveys are as follows:

1) Course Survey:

All the participants in a course can take the course survey.

File: course_evaluation_questionnaire.rb

2) Global Survey:

Any Expertiza user can take the global survey.

File: global_survey_questionnaire.rb

3) Targeted Survey:

The admin can create a survey targeted to a specific group of people.

File: survey_questionnaire.rb

== Class Design ==

=== Existing class structure: ===

[[File:E1734-structure-1.png|frame|center]]

=== Updated class structure: ===

[[File:E1734-structure-2New.jpg|frame|center]]

=== New Class Functionality: ===

==== Questionnaire: ====

Contains the basic information and methods required for posing questions to students or users in general. It is inherited by Classes Quiz, Survey, etc.

We can reuse this class's functionality to create, edit and delete surveys. The functionality for checking if questions have been answered can also be borrowed from this class.

==== Survey: ====

This project will introduce a new class called Survey.

This class will inherit from the Questionnaire class and it will be a superclass for the three different kinds of survey classes.

This class will include the assign_participants() method that can be used by any of the child classes to assign participants for their respective surveys.

This class will also have the statistics_generation functionality to be used to provide statistics for any kind of survey. This is the one that will take care of the requirement for getting the distribution of responses.

==== Global Survey: ====

This class will inherit from class Survey.

This class will be set the display_type for the survey to be global. So, while assigning participants all the users of Expertiza will be able to see this particular survey.

This kind of survey can only be created by admins of the Expertiza system.

==== Course Evaluation: ====

This is also another type of survey and will inherit from class Survey.

Surveys of this type, however, will only be available to the class to which this survey would be assigned. Accordingly, the display_type for it will be set to course.

So assign_participants() will create new survey participants for all users in a particular course.

==== Survey Questionnaire: ====

This class will also inherit from the class Survey. The name used for this class may change after further discussions with the professor.

The existing survey_questionnaire class will be repurposed to be used to create surveys that could be targeted to a group of users or be attached to a questionnaire.

It will allow for an association between an assignment and a questionnaire to be established. Additionally, it maintains the instructor id who will create the association.

A flag for a score outside an acceptable range will also be set. It could also be used to play a part in the total score calculation for the assignment.

== Database Schema ==

There are database tables that are used to track the deployment of the surveys, that are used to help keep track of the participants for each survey and that keep track of all the responses for the surveys we create. We would not be making any or would make only minimal design changes to these tables. Our main task would be to go in and fix things that are not currently operational given what we already have.

To give an idea about these database tables we have included them below.

Table: Survey Deployments

{| class="wikitable"
|-
! Element
! Type
! Attributes
|-
| course_evaluation_id
| Integer
| Limit: 4
|-
| start_date
| Datetime
|
|-
| end_date
| Datetime
|
|-
| num_of_students
| Integer
| Limit: 4
|-
| last_reminder
| Datetime
|
|-
| course_id
| Integer
| Limit: 4, Default: 0, Null: false
|}

Table: Survey Participants

{| class="wikitable"
|-
! Element
! Type
! Attributes
|-
| user_id
| Integer
| Limit: 4
|-
| survey_deployment_id
| Integer
| Limit: 4
|-
|}

Table: Survey Responses

{| class="wikitable"
|-
! Element
! Type
! Attributes
|-
| score
| Integer
| Limit: 4
|-
| comments
| Text
| Limit: 65535
|-
| assignment_id
| Integer
| Limit: 4, Default: 0, Nil: false
|-
| question_id
| Integer
| Limit: 4, Default: 0, Nil: false
|-
| survey_id
| Integer
| Limit: 4, Default: 0, Nil: false
|-
| email
| String
| Limit: 255
|}

== Tasks to be performed ==

Given the information at hand, the following list will provide a good summary of the tasks we will have to perform to achieve the goals of this project.

1) Change the hierarchical structure of classes. Make survey the child of questionnaire. Global survey, survey_questionnaire and course evaluation to be subclasses of survey.

2) Creation, editing and deletion of questions, is a functionality that would be inherited into class Survey(which is a kind of questionnaire) and so into all its children surveys, from the Questionnaire class.

3) Add new class Survey and include functionality to assign(which is in the survey_controller currently) to this model.

4) In the new class add functionality to generate statistics.

5) The display_type for each of the subclasses of Survey can be set individually in the post_initialization method.

6) The three kinds of surveys can be assigned to some either an assignment, a course, a student or to all the users of Expertiza depending on their display_type.

7) Use the course evaluation tab on the Expertiza homepage to display any pending surveys instead of just the course evaluation surveys. The course evaluation tab’s functionality is currently broken and needs to be fixed.

8) "Survey deployment" functionality is broken. Need to make survey deployment of all forms of surveys functional. This would include the following tasks:

a) Ability to add new survey deployments.
b) View responses to the deployments.
c) Delete deployments.

9) "Statistic generation for Survey" functionality is broken. From the drop down menu in survey deployments, we can select Statistical tests and that should take the user to a page where depending on the survey chosen the corresponding statistics would be displayed.

== Test Plan ==

Testing tool:

RSpec

{| class="wikitable"
|-
! Test #
! Description
|-
|Test case 1:
|Test to check whether an instructor can create a survey.
|-
|Test case 2:
|Test to check whether a survey is deleted.
|-
|Test case 3:
|Test to check whether a survey is updated.
|-
|Test case 4:
|Test to check whether a survey is deployed to the appropriate users.
|-
|Test case 5:
|Test to check whether the distribution of survey responses is correct.
|-
|Test case 6:
|Test to check whether a survey_participant record is created for the user in the participants table, if the user is assigned to take part in a survey.
|-
|}

CSC/ECE 517 Spring 2017/oss E1713

2017-03-31T03:43:17Z

Dpatel12: /* added changes of Late Policies Controller */

<font size="5">E1713. Refactor penalty_helper.rb and late_policies_controller.rb</font><br>
This project is intended to improve the code quality and reduce technical debt within the Expertiza system by refactoring the penalty_helper.rb module, refactoring the late_policies_controller.rb controller, and adding test coverage for both files.

==Introduction==

===Expertiza===
Expertiza is an open source web application which allows an instructor to manage assignments. It has various features viz. creating new assignments, customizing existing assignments, automatically allocating submissions for peer review etc. It has been developed using the [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] framework, and the code is available on [https://www.github.com/expertiza/expertiza Github].

===Project Goals===
In this project, the files [https://github.com/expertiza/expertiza/blob/master/app/controllers/late_policies_controller.rb late_policies_controller.rb] and [https://github.com/expertiza/expertiza/blob/master/app/helpers/penalty_helper.rb penalty_helper.rb] were to be refactored. The methods contained in these files were too long, and needed to be either shortened, or used polymorphically, or deleted altogether if they were not being used. They also were to be refactored semantically if the code did not follow good Ruby coding practices.

==Current Implementation==

===Late policies and penalties functionality===
After an instructor creates an assignment in Expertiza they will have the ability to edit the details of the assignment by clicking the Edit action icon beside the assignment. From the "Editing Assignment" screen instructors have the ability to set due dates for each round of an assignment on the "Due dates" tab. On this tab, the instructor can elect to apply a late policy to the assignment by checking the "Apply penalty policy" checkbox and selecting a late policy from the adjacent drop down menu. If no late policies exist, or if the instructor wishes to define a new late policy, then they can click the "New late policy" link to define a new late policy.

An instructor can define a late policy with the following fields:

* Late policy name - This name will show up in the drop down menu on the "Due dates" tab when editing the assignment. It is not enforced to be unique.
* Penalty Unit - With the options of 'Minute', 'Hour', and 'Day' this field will define the frequency with which penalty points are deducted if an assignment is submitted after a due date.
* Penalty Point Per Unit - This is the amount of points which will be deducted from the student's score for the assignment round every time the Penalty Unit time has elapsed between the due date and the submission date. [Range: > 50]
* Maximum Penalty - Points will continue to be deducted from the assignment round score for each Penalty Unit time that has elapsed, but the number of points deducted will not exceed the Maximum Penalty [Range: 1..50]

==Change specifics==
The penalty_helper.rb and late_policies_controller.rb files are central to the creation and maintenance of late policies. Late policies are created by instructors and associated with assignments. The late_policies_controller.rb file is primarily used in the communication with view where late policies are displayed, created, or modified. The penalty_helper.rb file includes many useful methods related to late policies and the penalties which result from their use. For instance, if an assignment is designated as having penalties calculated then when it is graded the PenaltyHelper module will allow the penalties for each assignment to be calculated and applied to the final grade for the assignment.

This effort was initiated with the intent of refactoring some longer methods with redundant subprocedures so that the overall structure of the code is cleaner, concise, and DRYer. This was achieved by performing analysis on the files to identify methods which are not used within the Expertiza code base, methods which are too long, and redundant code which can be extracted from other methods and replaced with a call to a single method.

===Late Policies Controller===
This is controller class for late policies. It handles all the basic operations on late policies like create/edit/delete policy. The project goal was to refactor the code of create and update methods to make them smaller and more readable. Three helper methods were added in the PenaltyHelper module to make the code shorter.
There was a common input check in both create and update methods which was separated to write two new methods "check_penalty_points_validity" and "check_policy_with_same_name", which helped to reuse the code.

#checking that penalty_per_unit is not exceeding max_penalty
def check_penalty_points_validity(max_penalty, penalty_per_unit)
if max_penalty < penalty_per_unit
flash[:error] = "The maximum penalty cannot be less than penalty per unit."
invalid_penalty_per_unit = true
else
invalid_penalty_per_unit = false
end
end

#method to check whether the policy name given as a parameter already exists under the current instructor id
#it return true if there's another policy with the same name under current instructor else false
def check_policy_with_same_name(late_policy_name)
@policy = LatePolicy.where(policy_name: late_policy_name)
if !@policy.nil? && !@policy.empty?
@policy.each do |p|
next unless p.instructor_id == instructor_id
return true
end
end
return false
end

In case of update action call, there was a part of code which was updating already calculated penalty objects based on the updated late policy. This part was written as a separate method in the helper class with name "update_calculated_penalty_objects".

def update_calculated_penalty_objects(penalty_policy)
@penaltyObjs = CalculatedPenalty.all
@penaltyObjs.each do |pen|
@participant = AssignmentParticipant.find(pen.participant_id)
@assignment = @participant.assignment
next unless @assignment.late_policy_id == penalty_policy.id
@penalties = calculate_penalty(pen.participant_id)
@total_penalty = (@penalties[:submission] + @penalties[:review] + @penalties[:meta_review])
if pen.deadline_type_id.to_i == 1
{penalty_points: @penalties[:submission]}
pen.update_attribute(:penalty_points, @penalties[:submission])
elsif pen.deadline_type_id.to_i == 2
{penalty_points: @penalties[:review]}
pen.update_attribute(:penalty_points, @penalties[:review])
elsif pen.deadline_type_id.to_i == 5
{penalty_points: @penalties[:meta_review]}
pen.update_attribute(:penalty_points, @penalties[:meta_review])
end
end
end

Some variable names were changed in order to make it easier for reader to understand the meaning of code.
There was some unused commented code which was removed.

===Penalty Helper===
This is a helper class which contains methods which calculate the different penalties, and are then brought together in one Hash object. The aim was to keep the methods below 25 lines of code if possible. Out of the numerous methods in the file, there were 3 substantial methods, namely calculate_penalty, calculate_submission_penalty, and compute_penalty_on_reviews crossed the 25 line limit.

calculate_penalty is the main method of the PenaltyHelper module. It is called from the [https://github.com/expertiza/expertiza/blob/master/app/controllers/grades_controller.rb GradesController] module. The other methods are called from within the calculate_penalty module. The method mainly contains a few assignment statements, and some method calls. There was no scope for it to be shortened further without risking non-operation of some functionalities.

A particular segment of code converted a time difference into respective unit. This code was inserted into a method with the parameter 'time_difference'. The conversion segment was called in calculate_submission_penalty, as well as compute_penalty_on_reviews. Inserting the conversion logic into a separate method allowed the simplification of both methods.

# The new method defined to convert time difference into respective unit
def calculate_penalty_minutes(time_difference)
if @penalty_unit == 'Minute'
penalty_minutes = time_difference / 60
elsif @penalty_unit == 'Hour'
penalty_minutes = time_difference / 3600
elsif @penalty_unit == 'Day'
penalty_minutes = time_difference / 86_400
end
end

The method was called in two places.

# Line 44
time_difference = last_submission_time - submission_due_date
penalty_minutes = calculate_penalty_minutes(time_difference)

# Line 109
time_difference = review_map_created_at_list.at(i) - review_due_date
penalty_minutes = calculate_penalty_minutes(time_difference)

Apart from the method which was defined, some other methods which were not being called were removed, extraneous statements which were written and then commented were also removed. Also, minor modifications in places where code did not follow Ruby grammar were made, for eg: a space was added between 'if' and the condition statement.

===Functional and integration testing===
Motivation behind testing including the technologies used for testing.

====penalty_helper_spec.rb====
Specific changes identified and made here, including the motivation behind making those changes.

====late_policies_controller_spec.rb====
Specific changes identified TO BE made here, including the motivation behind making those changes.

==Peer review validation==

===Validating application functionality===
Instructions on how our reviewers should validate the impacted functionality to ensure that it still works.

===Validating code via RSpec tests===

====Setup Expertiza VCL environment====
First, setup your Expertiza environment. Navigate to https://vcl.ncsu.edu and click the "Make a Reservation" button. Sign in with your Unity ID. Click the "Reservations" button and then click "New Reservation". In the environment drop down box select the ' [CSC517, F15] Ruby on Rails / Expertiza' environment, set your session duration, and click the "Create Reservation" button.

One your reservation is ready you should see a Connect! button. Click it and copy the IP address. If you don't have PuTTY then download it. Open PuTTY and paste the IP address in the hostname field and click "Open." Confirm connection at the security dialog. Log into the server using your Unity ID and password. Once logged in, execute the following commands to setup the Expertiza environment.

git clone https://github.com/michaelamoran/expertiza.git
cd expertiza
cp ./config/database.yml.example ./config/database.yml
cp ./config/secrets.yml.example ./config/secrets.yml
vi ./Gemfile
# Search for 'pg' and delete the line and save
bundle install
rake db:migrate
curl https://raw.githubusercontent.com/creationix/nvm/v0.13.1/install.sh | bash
source ~/.bash_profile
nvm install v7.7.3
npm install -g bower
bower install

# The following commands will prepare the test database so the tests don't fail.
rake db:create RAILS_ENV=test
rake db:migrate RAILS_ENV=test

====Executing tests====

Now, to run the tests, make sure you are in the project's root directory (i.e. ~/expertiza/). Run the following command:

rspec spec/helpers/penalty_helper_spec.rb

Once it is complete, the output should contain the number of test cases and how man of them passed or failed.