Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2018- Project E1816: Visualization for Instructors

2018-05-04T04:03:47Z

Mpan2: /* Testing Done */

__TOC__

===Team Members===
Daniel Burcal (djburcal@ncsu.edu)

Patrick Poggi (pfpoggi@ncsu.edu)

Ambareesh Pandit (aspandit@ncsu.edu)

Minghao Pan (mpan2@ncsu.edu)

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.

== Problem Statement ==

A previous team has worked on creating this visualization graphic for Instructors, which can be found [https://docs.google.com/document/d/1ybg9CK03_j3QtLI9R6vJqYunz8_I_pO9BX7iPGNe95o/edit# here]. We are tasked with building upon the work they have performed as well as improving the visualization aspect for instructors. Specifically we can narrow the goals of this project as follows:

:#The Visualization of the compiled metrics is confusing. We will aim to use a more coherent color scheme from red to green for the graph. We want to allow the instructor to dynamically generate graphs with the data they request. We will separate the table into partials or use a scheme to only show the sections of the table the instructor requests
:#There are ways to compile review data together such that it is even easier for the instructor to identify weaknesses and strengths. To that end, we would like to integrate review performance by compiling various feedback data that is collected. This would include the number of reviews performed, the length of the reviews, the summary of the reviews, whether or not the reviewers uploaded a file in their review, the average ratings the reviewers received from authors.
:#Another useful feature would be the ability to visualize class performance on a certain rubric criteria. Further, if these criteria are common ones used between projects, it would be very helpful to be able to compare performance between assignments on the common criteria.

== Design Process Flow ==

Below you can see a flowchart representing the graphical flow of an instructor visiting the visualization page we are modifying.

[[File:Final_Project_Graphic_Flow.jpg|center]]

Once the instructor visits the visualization page, they will already see a bar graph displaying how all the teams scored on each rubric criteria. Below this will be buttons or some other method by which to select the data that you want. The whole process flow involves being able to traverse the visualization page in a quick and efficient manner, since oftentimes the instructor will visit the page often. Below we will go into our intended design route for this project.

== Design ==

Here is a mock-up of our intended page:

[[File:Screen_Shot_2018-04-06_at_5.14.11_PM.png|center|]]

As you can see, we will have menu options by which the instructor can choose which data members to show and likewise the type of graphic visual they would like to produce. This will make it so that the instructors can visualize only the data they want to, and in the form that gives them the most relevant information. We plan on using the ''flot javascript library'' to implement the graphic visuals, which will provide an easy and clear visual of the requested data. Under the visual, we will have a way to select between teams and individual students' data to further target the desired visual. The last team which worked on this project used the ''highcharts javascript library'', but we have decided to move to ''flot'' due to visual clarity and the ability to easily decide which data to display.

Another mock-up of how the UI could be designed, is that by visiting the visualization page, the instructor will see a graph followed by an array of buttons.

[[File:ClassPerformanceStackedBarChartsWithToolTips.JPG‎|frame|center|alt=Stacked Bar|<div style="text-align: center">The source for this graph is at [https://jsfiddle.net/aspandit/ap3ba5gu/90/ jsfiddle] </div>]]

The chart above shows stacked bar charts of a single submission. Each bar represents a question from the submission and the colors represent the percentage of teams that earned a 0(red) through 5(green) on the submission.

[[File:Final_Project_Buttons.jpg|center]]

As you can see, we plan on implementing an array of buttons to carry out simple manipulations to data and to display only the data the instructor wants to. We plan on implementing buttons to change the graphic that is displayed, so that if an instructor wishes to see a pie chart or histogram, they can click the button and see the data in a different form. Below those buttons, there will be other ones which will direct the page on what type of table to display and with which information. The reason for these adjustments are that in the last semester's implementation, the table was quite lengthy, and this will make it more manageable by the instructor.

It is possible that if we are able to, we plan on implementing a drop down functionality like in the mock-up further up the page where you can be even more selective about the data you wish to display in the tables or in the graphics.

==Modified Files==
Generally we plan on modifying the same files as the previous group did. The controllers of grade and assignment are involved. For the view part, we will modify the view of grade and review_mapping. We may also create new view files.
app/controllers/grades_controller.rb

app/controllers/assignments_controller.rb

app/views/grades/view.html.erb (partials below)

app/views/grades/_teams.html.erb

app/views/grades/_team_title.html.erb

app/views/grades/_team_charts.html.erb

app/view/review_mapping/_review_report.html.erb

== Testing Plan ==
Since it is based on a previous project, we need to refactor some previous code while making sure the previous test files ('''assignments_controller_spec.rb''' and '''grades_controller_spec.rb''') still work. We are going to test new features we add in the future.

It is beyond the scope of the course to test the graphs. We will only test the Ruby code.The tests will most likely use RSpec and the existing factories in Expertiza.

As we will use Javascript to achieve an interactive visualization, we will test the functionality of Javascript codes manually.

== Implementation ==

=== Visualization ===

In order to Improve the visualization of the rubric question data, we decided to use the flot javascript library instead of highcharts. In order to accomplish this, we constructed an adapter that took the already generate highchart data by the previous team, and converted it to a representation required by our flot graph. This is done in the highchart_to_flot_adapter method in the app/controllers/grades_controller.rb file.

==== Color Scheme ====

For fixing the color scheme, we used the adapter that was made to obtain the correct data, and instead of using their randomly generated colors, in the adapter there was a 6 element array with colors from red to green. This was inputted into the data series as per the correct format flot requires. You can also see the result below, in the picture of the graph provided.

==== Rubric Representation ====

To implement this, in the adapter we formed the data series such that different review rounds would be separated and clustered among their own review questions. This allows an easier viewing of different review rounds in order to determine how the class improved. The data passed to the _team_charts.html.erb view file contains all of the questions for all review rounds associated with the assignment. In addition to implementing the flot graphical representation, we also created a tooltip which allows the instructor to see the percentage of people who scored a certain value on any rubric questions of any round.

Here is a picture of what the completed flot graph looks like:

[[File:Visualization_graph_complete.JPG |center]]

===Class Performance===
The Class Performance visualization allows the instructor to view a histogram of 0 to 5 scores for a particular assignment. Furthermore, the visualization allows the user to switch between the preliminary round and the final round as well as view a combined view. As with the rubric criteria visualization, hovering over a bar in the class performance visualization brings up a tooltip indicating the score and frequency of teams that earned that score.

[[File:Class_performance_graph.JPG‎|frame|center|alt=Stacked Bar|<div style="text-align: center">The source for this graph is at [https://jsfiddle.net/aspandit/ap3ba5gu/90/ jsfiddle] </div>]]

===Review Performance===
There some obsolete codes in review_mapping_helper.rb about Dr. Kidd's course. Those codes were intended to calculate author feedbacks of reviews and there are also some related codes in _review_report.html.erb. However, in the view part, those codes are commented and those do not work. In fact, Dr. Kidd's course is 806, which is not on Expertiza now. So those obsolete codes are removed. Since in the testing files there are no corresponding codes for those parts, the previous tests still work.
The new review table allows the instructor to sort the result by more options, like the number of reviews completed, the average volume and the average score. The page is given as below.

[[File:VirtualBox_Expertiza_Development_1_1_28_04_2018_23_24_38.png]]

==Testing Done==

===Rubric Representation===
In terms of ensuring correct operation of the system under the changes made, our goal was to ensure the previous tests worked, as not much was entirely changed about the view controller method. In ensuring the previous tests worked, we could then be sure the private methods within the grades_controller.rb file were working properly.

===Class Performance===
The tests verify that the correct frequency of raw scores is received from the database. A test is performed for rubric criteria that vary by round and one is created for an assignment where the rubric does not vary.

===Review Performance===
Some obsolete codes in the review_mapping_controller.rb are deleted and the previous test still works.

==Future Work==
One consideration to improve upon the work we have done, is to make it so that the visualization graph that shows participant performance on every rubric question in each round can handle assignments which vary the number of rubric questions between rounds. Currently the set-up does not support such a feature.

With regards to the class performance, an enhancement of showing the breakdown of weighted scores 0-100% could be shown instead of displaying the frequency of raw 0-5 scores.

The remaining challenge is to integrate the author feedback to the review report page. It is hard because of multiple reasons. Some reviews have 3 rounds. The feedback of each round has multiple questions. Some are scored questions but some are not. In fact, even the author feedback report does not include the specific score.

== References ==
Here is our project [https://github.com/aspandit/expertiza repo] <br />
Here is our created [https://github.com/expertiza/expertiza/pull/1167 Pull Request] <br />
Here is our video [https://www.youtube.com/watch?v=nKu3LyFvm4M&feature=youtu.be Visualization for Instructors Walkthrough]

CSC/ECE 517 Spring 2018- Project E1816: Visualization for Instructors

2018-05-04T04:01:59Z

Mpan2: /* Future Work */

__TOC__

===Team Members===
Daniel Burcal (djburcal@ncsu.edu)

Patrick Poggi (pfpoggi@ncsu.edu)

Ambareesh Pandit (aspandit@ncsu.edu)

Minghao Pan (mpan2@ncsu.edu)

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.

== Problem Statement ==

A previous team has worked on creating this visualization graphic for Instructors, which can be found [https://docs.google.com/document/d/1ybg9CK03_j3QtLI9R6vJqYunz8_I_pO9BX7iPGNe95o/edit# here]. We are tasked with building upon the work they have performed as well as improving the visualization aspect for instructors. Specifically we can narrow the goals of this project as follows:

:#The Visualization of the compiled metrics is confusing. We will aim to use a more coherent color scheme from red to green for the graph. We want to allow the instructor to dynamically generate graphs with the data they request. We will separate the table into partials or use a scheme to only show the sections of the table the instructor requests
:#There are ways to compile review data together such that it is even easier for the instructor to identify weaknesses and strengths. To that end, we would like to integrate review performance by compiling various feedback data that is collected. This would include the number of reviews performed, the length of the reviews, the summary of the reviews, whether or not the reviewers uploaded a file in their review, the average ratings the reviewers received from authors.
:#Another useful feature would be the ability to visualize class performance on a certain rubric criteria. Further, if these criteria are common ones used between projects, it would be very helpful to be able to compare performance between assignments on the common criteria.

== Design Process Flow ==

Below you can see a flowchart representing the graphical flow of an instructor visiting the visualization page we are modifying.

[[File:Final_Project_Graphic_Flow.jpg|center]]

Once the instructor visits the visualization page, they will already see a bar graph displaying how all the teams scored on each rubric criteria. Below this will be buttons or some other method by which to select the data that you want. The whole process flow involves being able to traverse the visualization page in a quick and efficient manner, since oftentimes the instructor will visit the page often. Below we will go into our intended design route for this project.

== Design ==

Here is a mock-up of our intended page:

[[File:Screen_Shot_2018-04-06_at_5.14.11_PM.png|center|]]

As you can see, we will have menu options by which the instructor can choose which data members to show and likewise the type of graphic visual they would like to produce. This will make it so that the instructors can visualize only the data they want to, and in the form that gives them the most relevant information. We plan on using the ''flot javascript library'' to implement the graphic visuals, which will provide an easy and clear visual of the requested data. Under the visual, we will have a way to select between teams and individual students' data to further target the desired visual. The last team which worked on this project used the ''highcharts javascript library'', but we have decided to move to ''flot'' due to visual clarity and the ability to easily decide which data to display.

Another mock-up of how the UI could be designed, is that by visiting the visualization page, the instructor will see a graph followed by an array of buttons.

[[File:ClassPerformanceStackedBarChartsWithToolTips.JPG‎|frame|center|alt=Stacked Bar|<div style="text-align: center">The source for this graph is at [https://jsfiddle.net/aspandit/ap3ba5gu/90/ jsfiddle] </div>]]

The chart above shows stacked bar charts of a single submission. Each bar represents a question from the submission and the colors represent the percentage of teams that earned a 0(red) through 5(green) on the submission.

[[File:Final_Project_Buttons.jpg|center]]

As you can see, we plan on implementing an array of buttons to carry out simple manipulations to data and to display only the data the instructor wants to. We plan on implementing buttons to change the graphic that is displayed, so that if an instructor wishes to see a pie chart or histogram, they can click the button and see the data in a different form. Below those buttons, there will be other ones which will direct the page on what type of table to display and with which information. The reason for these adjustments are that in the last semester's implementation, the table was quite lengthy, and this will make it more manageable by the instructor.

It is possible that if we are able to, we plan on implementing a drop down functionality like in the mock-up further up the page where you can be even more selective about the data you wish to display in the tables or in the graphics.

==Modified Files==
Generally we plan on modifying the same files as the previous group did. The controllers of grade and assignment are involved. For the view part, we will modify the view of grade and review_mapping. We may also create new view files.
app/controllers/grades_controller.rb

app/controllers/assignments_controller.rb

app/views/grades/view.html.erb (partials below)

app/views/grades/_teams.html.erb

app/views/grades/_team_title.html.erb

app/views/grades/_team_charts.html.erb

app/view/review_mapping/_review_report.html.erb

== Testing Plan ==
Since it is based on a previous project, we need to refactor some previous code while making sure the previous test files ('''assignments_controller_spec.rb''' and '''grades_controller_spec.rb''') still work. We are going to test new features we add in the future.

It is beyond the scope of the course to test the graphs. We will only test the Ruby code.The tests will most likely use RSpec and the existing factories in Expertiza.

As we will use Javascript to achieve an interactive visualization, we will test the functionality of Javascript codes manually.

== Implementation ==

=== Visualization ===

In order to Improve the visualization of the rubric question data, we decided to use the flot javascript library instead of highcharts. In order to accomplish this, we constructed an adapter that took the already generate highchart data by the previous team, and converted it to a representation required by our flot graph. This is done in the highchart_to_flot_adapter method in the app/controllers/grades_controller.rb file.

==== Color Scheme ====

For fixing the color scheme, we used the adapter that was made to obtain the correct data, and instead of using their randomly generated colors, in the adapter there was a 6 element array with colors from red to green. This was inputted into the data series as per the correct format flot requires. You can also see the result below, in the picture of the graph provided.

==== Rubric Representation ====

To implement this, in the adapter we formed the data series such that different review rounds would be separated and clustered among their own review questions. This allows an easier viewing of different review rounds in order to determine how the class improved. The data passed to the _team_charts.html.erb view file contains all of the questions for all review rounds associated with the assignment. In addition to implementing the flot graphical representation, we also created a tooltip which allows the instructor to see the percentage of people who scored a certain value on any rubric questions of any round.

Here is a picture of what the completed flot graph looks like:

[[File:Visualization_graph_complete.JPG |center]]

===Class Performance===
The Class Performance visualization allows the instructor to view a histogram of 0 to 5 scores for a particular assignment. Furthermore, the visualization allows the user to switch between the preliminary round and the final round as well as view a combined view. As with the rubric criteria visualization, hovering over a bar in the class performance visualization brings up a tooltip indicating the score and frequency of teams that earned that score.

[[File:Class_performance_graph.JPG‎|frame|center|alt=Stacked Bar|<div style="text-align: center">The source for this graph is at [https://jsfiddle.net/aspandit/ap3ba5gu/90/ jsfiddle] </div>]]

===Review Performance===
There some obsolete codes in review_mapping_helper.rb about Dr. Kidd's course. Those codes were intended to calculate author feedbacks of reviews and there are also some related codes in _review_report.html.erb. However, in the view part, those codes are commented and those do not work. In fact, Dr. Kidd's course is 806, which is not on Expertiza now. So those obsolete codes are removed. Since in the testing files there are no corresponding codes for those parts, the previous tests still work.
The new review table allows the instructor to sort the result by more options, like the number of reviews completed, the average volume and the average score. The page is given as below.

[[File:VirtualBox_Expertiza_Development_1_1_28_04_2018_23_24_38.png]]

==Testing Done==

===Rubric Representation===
In terms of ensuring correct operation of the system under the changes made, our goal was to ensure the previous tests worked, as not much was entirely changed about the view controller method. In ensuring the previous tests worked, we could then be sure the private methods within the grades_controller.rb file were working properly.

===Class Performance===
The tests verify that the correct frequency of raw scores is received from the database. A test is performed for rubric criteria that varies by round and one is created for an assignment where the rubric does not vary.

==Future Work==
One consideration to improve upon the work we have done, is to make it so that the visualization graph that shows participant performance on every rubric question in each round can handle assignments which vary the number of rubric questions between rounds. Currently the set-up does not support such a feature.

With regards to the class performance, an enhancement of showing the breakdown of weighted scores 0-100% could be shown instead of displaying the frequency of raw 0-5 scores.

The remaining challenge is to integrate the author feedback to the review report page. It is hard because of multiple reasons. Some reviews have 3 rounds. The feedback of each round has multiple questions. Some are scored questions but some are not. In fact, even the author feedback report does not include the specific score.

== References ==
Here is our project [https://github.com/aspandit/expertiza repo] <br />
Here is our created [https://github.com/expertiza/expertiza/pull/1167 Pull Request] <br />
Here is our video [https://www.youtube.com/watch?v=nKu3LyFvm4M&feature=youtu.be Visualization for Instructors Walkthrough]

CSC/ECE 517 Spring 2018- Project E1816: Visualization for Instructors

2018-05-04T04:01:30Z

Mpan2: /* Review Performance */

__TOC__

===Team Members===
Daniel Burcal (djburcal@ncsu.edu)

Patrick Poggi (pfpoggi@ncsu.edu)

Ambareesh Pandit (aspandit@ncsu.edu)

Minghao Pan (mpan2@ncsu.edu)

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.

== Problem Statement ==

A previous team has worked on creating this visualization graphic for Instructors, which can be found [https://docs.google.com/document/d/1ybg9CK03_j3QtLI9R6vJqYunz8_I_pO9BX7iPGNe95o/edit# here]. We are tasked with building upon the work they have performed as well as improving the visualization aspect for instructors. Specifically we can narrow the goals of this project as follows:

:#The Visualization of the compiled metrics is confusing. We will aim to use a more coherent color scheme from red to green for the graph. We want to allow the instructor to dynamically generate graphs with the data they request. We will separate the table into partials or use a scheme to only show the sections of the table the instructor requests
:#There are ways to compile review data together such that it is even easier for the instructor to identify weaknesses and strengths. To that end, we would like to integrate review performance by compiling various feedback data that is collected. This would include the number of reviews performed, the length of the reviews, the summary of the reviews, whether or not the reviewers uploaded a file in their review, the average ratings the reviewers received from authors.
:#Another useful feature would be the ability to visualize class performance on a certain rubric criteria. Further, if these criteria are common ones used between projects, it would be very helpful to be able to compare performance between assignments on the common criteria.

== Design Process Flow ==

Below you can see a flowchart representing the graphical flow of an instructor visiting the visualization page we are modifying.

[[File:Final_Project_Graphic_Flow.jpg|center]]

Once the instructor visits the visualization page, they will already see a bar graph displaying how all the teams scored on each rubric criteria. Below this will be buttons or some other method by which to select the data that you want. The whole process flow involves being able to traverse the visualization page in a quick and efficient manner, since oftentimes the instructor will visit the page often. Below we will go into our intended design route for this project.

== Design ==

Here is a mock-up of our intended page:

[[File:Screen_Shot_2018-04-06_at_5.14.11_PM.png|center|]]

As you can see, we will have menu options by which the instructor can choose which data members to show and likewise the type of graphic visual they would like to produce. This will make it so that the instructors can visualize only the data they want to, and in the form that gives them the most relevant information. We plan on using the ''flot javascript library'' to implement the graphic visuals, which will provide an easy and clear visual of the requested data. Under the visual, we will have a way to select between teams and individual students' data to further target the desired visual. The last team which worked on this project used the ''highcharts javascript library'', but we have decided to move to ''flot'' due to visual clarity and the ability to easily decide which data to display.

Another mock-up of how the UI could be designed, is that by visiting the visualization page, the instructor will see a graph followed by an array of buttons.

[[File:ClassPerformanceStackedBarChartsWithToolTips.JPG‎|frame|center|alt=Stacked Bar|<div style="text-align: center">The source for this graph is at [https://jsfiddle.net/aspandit/ap3ba5gu/90/ jsfiddle] </div>]]

The chart above shows stacked bar charts of a single submission. Each bar represents a question from the submission and the colors represent the percentage of teams that earned a 0(red) through 5(green) on the submission.

[[File:Final_Project_Buttons.jpg|center]]

As you can see, we plan on implementing an array of buttons to carry out simple manipulations to data and to display only the data the instructor wants to. We plan on implementing buttons to change the graphic that is displayed, so that if an instructor wishes to see a pie chart or histogram, they can click the button and see the data in a different form. Below those buttons, there will be other ones which will direct the page on what type of table to display and with which information. The reason for these adjustments are that in the last semester's implementation, the table was quite lengthy, and this will make it more manageable by the instructor.

It is possible that if we are able to, we plan on implementing a drop down functionality like in the mock-up further up the page where you can be even more selective about the data you wish to display in the tables or in the graphics.

==Modified Files==
Generally we plan on modifying the same files as the previous group did. The controllers of grade and assignment are involved. For the view part, we will modify the view of grade and review_mapping. We may also create new view files.
app/controllers/grades_controller.rb

app/controllers/assignments_controller.rb

app/views/grades/view.html.erb (partials below)

app/views/grades/_teams.html.erb

app/views/grades/_team_title.html.erb

app/views/grades/_team_charts.html.erb

app/view/review_mapping/_review_report.html.erb

== Testing Plan ==
Since it is based on a previous project, we need to refactor some previous code while making sure the previous test files ('''assignments_controller_spec.rb''' and '''grades_controller_spec.rb''') still work. We are going to test new features we add in the future.

It is beyond the scope of the course to test the graphs. We will only test the Ruby code.The tests will most likely use RSpec and the existing factories in Expertiza.

As we will use Javascript to achieve an interactive visualization, we will test the functionality of Javascript codes manually.

== Implementation ==

=== Visualization ===

In order to Improve the visualization of the rubric question data, we decided to use the flot javascript library instead of highcharts. In order to accomplish this, we constructed an adapter that took the already generate highchart data by the previous team, and converted it to a representation required by our flot graph. This is done in the highchart_to_flot_adapter method in the app/controllers/grades_controller.rb file.

==== Color Scheme ====

For fixing the color scheme, we used the adapter that was made to obtain the correct data, and instead of using their randomly generated colors, in the adapter there was a 6 element array with colors from red to green. This was inputted into the data series as per the correct format flot requires. You can also see the result below, in the picture of the graph provided.

==== Rubric Representation ====

To implement this, in the adapter we formed the data series such that different review rounds would be separated and clustered among their own review questions. This allows an easier viewing of different review rounds in order to determine how the class improved. The data passed to the _team_charts.html.erb view file contains all of the questions for all review rounds associated with the assignment. In addition to implementing the flot graphical representation, we also created a tooltip which allows the instructor to see the percentage of people who scored a certain value on any rubric questions of any round.

Here is a picture of what the completed flot graph looks like:

[[File:Visualization_graph_complete.JPG |center]]

===Class Performance===
The Class Performance visualization allows the instructor to view a histogram of 0 to 5 scores for a particular assignment. Furthermore, the visualization allows the user to switch between the preliminary round and the final round as well as view a combined view. As with the rubric criteria visualization, hovering over a bar in the class performance visualization brings up a tooltip indicating the score and frequency of teams that earned that score.

[[File:Class_performance_graph.JPG‎|frame|center|alt=Stacked Bar|<div style="text-align: center">The source for this graph is at [https://jsfiddle.net/aspandit/ap3ba5gu/90/ jsfiddle] </div>]]

===Review Performance===
There some obsolete codes in review_mapping_helper.rb about Dr. Kidd's course. Those codes were intended to calculate author feedbacks of reviews and there are also some related codes in _review_report.html.erb. However, in the view part, those codes are commented and those do not work. In fact, Dr. Kidd's course is 806, which is not on Expertiza now. So those obsolete codes are removed. Since in the testing files there are no corresponding codes for those parts, the previous tests still work.
The new review table allows the instructor to sort the result by more options, like the number of reviews completed, the average volume and the average score. The page is given as below.

[[File:VirtualBox_Expertiza_Development_1_1_28_04_2018_23_24_38.png]]

==Testing Done==

===Rubric Representation===
In terms of ensuring correct operation of the system under the changes made, our goal was to ensure the previous tests worked, as not much was entirely changed about the view controller method. In ensuring the previous tests worked, we could then be sure the private methods within the grades_controller.rb file were working properly.

===Class Performance===
The tests verify that the correct frequency of raw scores is received from the database. A test is performed for rubric criteria that varies by round and one is created for an assignment where the rubric does not vary.

==Future Work==
One consideration to improve upon the work we have done, is to make it so that the visualization graph that shows participant performance on every rubric question in each round can handle assignments which vary the number of rubric questions between rounds. Currently the set-up does not support such a feature.

With regards to the class performance, an enhancement of showing the breakdown of weighted scores 0-100% could be shown instead of displaying the frequency of raw 0-5 scores.

== References ==
Here is our project [https://github.com/aspandit/expertiza repo] <br />
Here is our created [https://github.com/expertiza/expertiza/pull/1167 Pull Request] <br />
Here is our video [https://www.youtube.com/watch?v=nKu3LyFvm4M&feature=youtu.be Visualization for Instructors Walkthrough]

CSC/ECE 517 Spring 2018- Project E1816: Visualization for Instructors

2018-04-29T03:49:53Z

Mpan2: /* Review Performance */

__TOC__

===Team Members===
Daniel Burcal (djburcal@ncsu.edu)

Patrick Poggi (pfpoggi@ncsu.edu)

Ambareesh Pandit (aspandit@ncsu.edu)

Minghao Pan (mpan2@ncsu.edu)

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.

== Problem Statement ==

A previous team has worked on creating this visualization graphic for Instructors, which can be found [https://docs.google.com/document/d/1ybg9CK03_j3QtLI9R6vJqYunz8_I_pO9BX7iPGNe95o/edit# here]. We are tasked with building upon the work they have performed as well as improving the visualization aspect for instructors. Specifically we can narrow the goals of this project as follows:

:#The Visualization of the compiled metrics is confusing. We will aim to use a more coherent color scheme from red to green for the graph. We want to allow the instructor to dynamically generate graphs with the data they request. We will separate the table into partials or use a scheme to only show the sections of the table the instructor requests
:#There are ways to compile review data together such that it is even easier for the instructor to identify weaknesses and strengths. To that end, we would like to integrate review performance by compiling various feedback data that is collected. This would include the number of reviews performed, the length of the reviews, the summary of the reviews, whether or not the reviewers uploaded a file in their review, the average ratings the reviewers received from authors.
:#Another useful feature would be the ability to visualize class performance on a certain rubric criteria. Further, if these criteria are common ones used between projects, it would be very helpful to be able to compare performance between assignments on the common criteria.

== Design Process Flow ==

Below you can see a flowchart representing the graphical flow of an instructor visiting the visualization page we are modifying.

[[File:Final_Project_Graphic_Flow.jpg|center]]

Once the instructor visits the visualization page, they will already see a bar graph displaying how all the teams scored on each rubric criteria. Below this will be buttons or some other method by which to select the data that you want. The whole process flow involves being able to traverse the visualization page in a quick and efficient manner, since oftentimes the instructor will visit the page often. Below we will go into our intended design route for this project.

== Design ==

Here is a mock-up of our intended page:

[[File:Screen_Shot_2018-04-06_at_5.14.11_PM.png|center|]]

As you can see, we will have menu options by which the instructor can choose which data members to show and likewise the type of graphic visual they would like to produce. This will make it so that the instructors can visualize only the data they want to, and in the form that gives them the most relevant information. We plan on using the ''flot javascript library'' to implement the graphic visuals, which will provide an easy and clear visual of the requested data. Under the visual, we will have a way to select between teams and individual students' data to further target the desired visual. The last team which worked on this project used the ''highcharts javascript library'', but we have decided to move to ''flot'' due to visual clarity and the ability to easily decide which data to display.

Another mock-up of how the UI could be designed, is that by visiting the visualization page, the instructor will see a graph followed by an array of buttons.

[[File:ClassPerformanceStackedBarChartsWithToolTips.JPG‎|frame|center|alt=Stacked Bar|<div style="text-align: center">The source for this graph is at [https://jsfiddle.net/aspandit/ap3ba5gu/90/ jsfiddle] </div>]]

The chart above shows stacked bar charts of a single submission. Each bar represents a question from the submission and the colors represent the percentage of teams that earned a 0(red) through 5(green) on the submission.

[[File:Final_Project_Buttons.jpg|center]]

As you can see, we plan on implementing an array of buttons to carry out simple manipulations to data and to display only the data the instructor wants to. We plan on implementing buttons to change the graphic that is displayed, so that if an instructor wishes to see a pie chart or histogram, they can click the button and see the data in a different form. Below those buttons, there will be other ones which will direct the page on what type of table to display and with which information. The reason for these adjustments are that in the last semester's implementation, the table was quite lengthy, and this will make it more manageable by the instructor.

It is possible that if we are able to, we plan on implementing a drop down functionality like in the mock-up further up the page where you can be even more selective about the data you wish to display in the tables or in the graphics.

==Modified Files==
Generally we plan on modifying the same files as the previous group did. The controllers of grade and assignment are involved. For the view part, we will modify the view of grade and review_mapping. We may also create new view files.
app/controllers/grades_controller.rb

app/controllers/assignments_controller.rb

app/views/grades/view.html.erb (partials below)

app/views/grades/_teams.html.erb

app/views/grades/_team_title.html.erb

app/views/grades/_team_charts.html.erb

app/view/review_mapping/_review_report.html.erb

== Testing Plan ==
Since it is based on a previous project, we need to refactor some previous code while making sure the previous test files ('''assignments_controller_spec.rb''' and '''grades_controller_spec.rb''') still work. We are going to test new features we add in the future.

It is beyond the scope of the course to test the graphs. We will only test the Ruby code.The tests will most likely use RSpec and the existing factories in Expertiza.

As we will use Javascript to achieve an interactive visualization, we will test the functionality of Javascript codes manually.

== Implementation ==

=== Visualization ===

In order to Improve the visualization of the rubric question data, we decided to use the flot javascript library instead of highcharts. In order to accomplish this, we constructed an adapter that took the already generate highchart data by the previous team, and converted it to a representation required by our flot graph. This is done in the highchart_to_flot_adapter method in the app/controllers/grades_controller.rb file.

==== Color Scheme ====

For fixing the color scheme, we used the adapter that was made to obtain the correct data, and instead of using their randomly generated colors, in the adapter there was a 6 element array with colors from red to green. This was inputted into the data series as per the correct format flot requires.

==== Rubric Representation ====

To implement this, in the adapter we formed the data series such that different review rounds would be separated and clustered among their own review questions. This allows an easier viewing of different review rounds in order to determine how the class improved. The data passed to the _team_charts.html.erb view file contains all of the questions for all review rounds associated with the assignment.

===Class Performance===
The Class Performance visualization will allow the instructor to view a histogram of 0 to 5 scores for a particular assignment. Furthermore, the visualization will allow the user to switch between the preliminary submission and the final submission as well as view a combined view.

===Review Performance===
There some obsolete codes in review_mapping_helper.rb about Dr. Kidd's course. Those codes were intended to calculate author feedbacks of reviews and there are also some related codes in _review_report.html.erb. However, in the view part, those codes are commented and those do not work. In fact, Dr. Kidd's course is 806, which is not on Expertiza now. So those obsolete codes are removed. Since in the testing files there are no corresponding codes for those parts, the previous tests still work.
The new review table allows the instructor to sort the result by more options, like the number of reviews completed, the average volume and the average score. The page is given as below.
[[File:VirtualBox_Expertiza_Development_1_1_28_04_2018_23_24_38.png]]

The remaining challenge is to integrate the author feedback to the review report page. It is hard because of multiple reasons. Some reviews have 3 rounds. The feedback of each round has multiple questions. Some are scored questions but some are not. In fact, even the author feedback report does not include the specific score.

== Pending Tasks ==

Currently our project is not complete end to end. It is our hope to complete various aspects in order have a more fruitful demo. That being said, the visualization changes are currently suffering difficulties in data formatting. Right now the data is collected correctly, just a few manipulations need to be done on it. The current state is as you can see below. We plan on fixing the graphical formatting slightly, making it larger, reversing the graph so review round shows first, and making it so that the data is in the form of percentages that add up to 100.

[[File:Visualization_graph_almost_done.PNG |center]]

== References ==
Here is our project [https://github.com/aspandit/expertiza repo] <br />
Here is our created [https://github.com/expertiza/expertiza/pull/1167 Pull Request]

CSC/ECE 517 Spring 2018- Project E1816: Visualization for Instructors

2018-04-29T03:44:11Z

Mpan2: /* Review Performance */

__TOC__

===Team Members===
Daniel Burcal (djburcal@ncsu.edu)

Patrick Poggi (pfpoggi@ncsu.edu)

Ambareesh Pandit (aspandit@ncsu.edu)

Minghao Pan (mpan2@ncsu.edu)

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.

== Problem Statement ==

A previous team has worked on creating this visualization graphic for Instructors, which can be found [https://docs.google.com/document/d/1ybg9CK03_j3QtLI9R6vJqYunz8_I_pO9BX7iPGNe95o/edit# here]. We are tasked with building upon the work they have performed as well as improving the visualization aspect for instructors. Specifically we can narrow the goals of this project as follows:

:#The Visualization of the compiled metrics is confusing. We will aim to use a more coherent color scheme from red to green for the graph. We want to allow the instructor to dynamically generate graphs with the data they request. We will separate the table into partials or use a scheme to only show the sections of the table the instructor requests
:#There are ways to compile review data together such that it is even easier for the instructor to identify weaknesses and strengths. To that end, we would like to integrate review performance by compiling various feedback data that is collected. This would include the number of reviews performed, the length of the reviews, the summary of the reviews, whether or not the reviewers uploaded a file in their review, the average ratings the reviewers received from authors.
:#Another useful feature would be the ability to visualize class performance on a certain rubric criteria. Further, if these criteria are common ones used between projects, it would be very helpful to be able to compare performance between assignments on the common criteria.

== Design Process Flow ==

Below you can see a flowchart representing the graphical flow of an instructor visiting the visualization page we are modifying.

[[File:Final_Project_Graphic_Flow.jpg|center]]

Once the instructor visits the visualization page, they will already see a bar graph displaying how all the teams scored on each rubric criteria. Below this will be buttons or some other method by which to select the data that you want. The whole process flow involves being able to traverse the visualization page in a quick and efficient manner, since oftentimes the instructor will visit the page often. Below we will go into our intended design route for this project.

== Design ==

Here is a mock-up of our intended page:

[[File:Screen_Shot_2018-04-06_at_5.14.11_PM.png|center|]]

As you can see, we will have menu options by which the instructor can choose which data members to show and likewise the type of graphic visual they would like to produce. This will make it so that the instructors can visualize only the data they want to, and in the form that gives them the most relevant information. We plan on using the ''flot javascript library'' to implement the graphic visuals, which will provide an easy and clear visual of the requested data. Under the visual, we will have a way to select between teams and individual students' data to further target the desired visual. The last team which worked on this project used the ''highcharts javascript library'', but we have decided to move to ''flot'' due to visual clarity and the ability to easily decide which data to display.

Another mock-up of how the UI could be designed, is that by visiting the visualization page, the instructor will see a graph followed by an array of buttons.

[[File:ClassPerformanceStackedBarChartsWithToolTips.JPG‎|frame|center|alt=Stacked Bar|<div style="text-align: center">The source for this graph is at [https://jsfiddle.net/aspandit/ap3ba5gu/90/ jsfiddle] </div>]]

The chart above shows stacked bar charts of a single submission. Each bar represents a question from the submission and the colors represent the percentage of teams that earned a 0(red) through 5(green) on the submission.

[[File:Final_Project_Buttons.jpg|center]]

As you can see, we plan on implementing an array of buttons to carry out simple manipulations to data and to display only the data the instructor wants to. We plan on implementing buttons to change the graphic that is displayed, so that if an instructor wishes to see a pie chart or histogram, they can click the button and see the data in a different form. Below those buttons, there will be other ones which will direct the page on what type of table to display and with which information. The reason for these adjustments are that in the last semester's implementation, the table was quite lengthy, and this will make it more manageable by the instructor.

It is possible that if we are able to, we plan on implementing a drop down functionality like in the mock-up further up the page where you can be even more selective about the data you wish to display in the tables or in the graphics.

==Modified Files==
Generally we plan on modifying the same files as the previous group did. The controllers of grade and assignment are involved. For the view part, we will modify the view of grade and review_mapping. We may also create new view files.
app/controllers/grades_controller.rb

app/controllers/assignments_controller.rb

app/views/grades/view.html.erb (partials below)

app/views/grades/_teams.html.erb

app/views/grades/_team_title.html.erb

app/views/grades/_team_charts.html.erb

app/view/review_mapping/_review_report.html.erb

== Testing Plan ==
Since it is based on a previous project, we need to refactor some previous code while making sure the previous test files ('''assignments_controller_spec.rb''' and '''grades_controller_spec.rb''') still work. We are going to test new features we add in the future.

It is beyond the scope of the course to test the graphs. We will only test the Ruby code.The tests will most likely use RSpec and the existing factories in Expertiza.

As we will use Javascript to achieve an interactive visualization, we will test the functionality of Javascript codes manually.

== Implementation ==

=== Visualization ===

In order to Improve the visualization of the rubric question data, we decided to use the flot javascript library instead of highcharts. In order to accomplish this, we constructed an adapter that took the already generate highchart data by the previous team, and converted it to a representation required by our flot graph. This is done in the highchart_to_flot_adapter method in the app/controllers/grades_controller.rb file.

==== Color Scheme ====

For fixing the color scheme, we used the adapter that was made to obtain the correct data, and instead of using their randomly generated colors, in the adapter there was a 6 element array with colors from red to green. This was inputted into the data series as per the correct format flot requires.

==== Rubric Representation ====

To implement this, in the adapter we formed the data series such that different review rounds would be separated and clustered among their own review questions. This allows an easier viewing of different review rounds in order to determine how the class improved. The data passed to the _team_charts.html.erb view file contains all of the questions for all review rounds associated with the assignment.

===Class Performance===
The Class Performance visualization will allow the instructor to view a histogram of 0 to 5 scores for a particular assignment. Furthermore, the visualization will allow the user to switch between the preliminary submission and the final submission as well as view a combined view.

===Review Performance===
There some obsolete codes in review_mapping_helper.rb about Dr. Kidd's course. Those codes were intended to calculate author feedbacks of reviews and there are also some related codes in _review_report.html.erb. However, in the view part, those codes are commented and those do not work. In fact, Dr. Kidd's course is 806, which is not on Expertiza now. So those obsolete codes are removed. Since in the testing files there are no corresponding codes for those parts, the previous tests still work.
The new review table allows the instructor to sort the result by more options, like the number of reviews completed, the average volume and the average score. The
[[File:VirtualBox_Expertiza_Development_1_1_28_04_2018_23_24_38.png]]

== Pending Tasks ==

Currently our project is not complete end to end. It is our hope to complete various aspects in order have a more fruitful demo. That being said, the visualization changes are currently suffering difficulties in data formatting. For that task the front end is already complete as can be seen above.

== References ==
Here is our project [https://github.com/aspandit/expertiza repo] <br />
Here is our created [https://github.com/expertiza/expertiza/pull/1167 Pull Request]

File:VirtualBox Expertiza Development 1 1 28 04 2018 23 24 38.png

2018-04-29T03:44:05Z

Mpan2: uploaded a new version of "File:VirtualBox Expertiza Development 1 1 28 04 2018 23 24 38.png"

CSC/ECE 517 Spring 2018- Project E1816: Visualization for Instructors

2018-04-29T03:42:24Z

Mpan2: /* Review Performance */

__TOC__

===Team Members===
Daniel Burcal (djburcal@ncsu.edu)

Patrick Poggi (pfpoggi@ncsu.edu)

Ambareesh Pandit (aspandit@ncsu.edu)

Minghao Pan (mpan2@ncsu.edu)

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.

== Problem Statement ==

A previous team has worked on creating this visualization graphic for Instructors, which can be found [https://docs.google.com/document/d/1ybg9CK03_j3QtLI9R6vJqYunz8_I_pO9BX7iPGNe95o/edit# here]. We are tasked with building upon the work they have performed as well as improving the visualization aspect for instructors. Specifically we can narrow the goals of this project as follows:

:#The Visualization of the compiled metrics is confusing. We will aim to use a more coherent color scheme from red to green for the graph. We want to allow the instructor to dynamically generate graphs with the data they request. We will separate the table into partials or use a scheme to only show the sections of the table the instructor requests
:#There are ways to compile review data together such that it is even easier for the instructor to identify weaknesses and strengths. To that end, we would like to integrate review performance by compiling various feedback data that is collected. This would include the number of reviews performed, the length of the reviews, the summary of the reviews, whether or not the reviewers uploaded a file in their review, the average ratings the reviewers received from authors.
:#Another useful feature would be the ability to visualize class performance on a certain rubric criteria. Further, if these criteria are common ones used between projects, it would be very helpful to be able to compare performance between assignments on the common criteria.

== Design Process Flow ==

Below you can see a flowchart representing the graphical flow of an instructor visiting the visualization page we are modifying.

[[File:Final_Project_Graphic_Flow.jpg|center]]

Once the instructor visits the visualization page, they will already see a bar graph displaying how all the teams scored on each rubric criteria. Below this will be buttons or some other method by which to select the data that you want. The whole process flow involves being able to traverse the visualization page in a quick and efficient manner, since oftentimes the instructor will visit the page often. Below we will go into our intended design route for this project.

== Design ==

Here is a mock-up of our intended page:

[[File:Screen_Shot_2018-04-06_at_5.14.11_PM.png|center|]]

As you can see, we will have menu options by which the instructor can choose which data members to show and likewise the type of graphic visual they would like to produce. This will make it so that the instructors can visualize only the data they want to, and in the form that gives them the most relevant information. We plan on using the ''flot javascript library'' to implement the graphic visuals, which will provide an easy and clear visual of the requested data. Under the visual, we will have a way to select between teams and individual students' data to further target the desired visual. The last team which worked on this project used the ''highcharts javascript library'', but we have decided to move to ''flot'' due to visual clarity and the ability to easily decide which data to display.

Another mock-up of how the UI could be designed, is that by visiting the visualization page, the instructor will see a graph followed by an array of buttons.

[[File:ClassPerformanceStackedBarChartsWithToolTips.JPG‎|frame|center|alt=Stacked Bar|<div style="text-align: center">The source for this graph is at [https://jsfiddle.net/aspandit/ap3ba5gu/90/ jsfiddle] </div>]]

The chart above shows stacked bar charts of a single submission. Each bar represents a question from the submission and the colors represent the percentage of teams that earned a 0(red) through 5(green) on the submission.

[[File:Final_Project_Buttons.jpg|center]]

As you can see, we plan on implementing an array of buttons to carry out simple manipulations to data and to display only the data the instructor wants to. We plan on implementing buttons to change the graphic that is displayed, so that if an instructor wishes to see a pie chart or histogram, they can click the button and see the data in a different form. Below those buttons, there will be other ones which will direct the page on what type of table to display and with which information. The reason for these adjustments are that in the last semester's implementation, the table was quite lengthy, and this will make it more manageable by the instructor.

It is possible that if we are able to, we plan on implementing a drop down functionality like in the mock-up further up the page where you can be even more selective about the data you wish to display in the tables or in the graphics.

==Modified Files==
Generally we plan on modifying the same files as the previous group did. The controllers of grade and assignment are involved. For the view part, we will modify the view of grade and review_mapping. We may also create new view files.
app/controllers/grades_controller.rb

app/controllers/assignments_controller.rb

app/views/grades/view.html.erb (partials below)

app/views/grades/_teams.html.erb

app/views/grades/_team_title.html.erb

app/views/grades/_team_charts.html.erb

app/view/review_mapping/_review_report.html.erb

== Testing Plan ==
Since it is based on a previous project, we need to refactor some previous code while making sure the previous test files ('''assignments_controller_spec.rb''' and '''grades_controller_spec.rb''') still work. We are going to test new features we add in the future.

It is beyond the scope of the course to test the graphs. We will only test the Ruby code.The tests will most likely use RSpec and the existing factories in Expertiza.

As we will use Javascript to achieve an interactive visualization, we will test the functionality of Javascript codes manually.

== Implementation ==

=== Visualization ===

In order to Improve the visualization of the rubric question data, we decided to use the flot javascript library instead of highcharts. In order to accomplish this, we constructed an adapter that took the already generate highchart data by the previous team, and converted it to a representation required by our flot graph. This is done in the highchart_to_flot_adapter method in the app/controllers/grades_controller.rb file.

==== Color Scheme ====

For fixing the color scheme, we used the adapter that was made to obtain the correct data, and instead of using their randomly generated colors, in the adapter there was a 6 element array with colors from red to green. This was inputted into the data series as per the correct format flot requires.

==== Rubric Representation ====

To implement this, in the adapter we formed the data series such that different review rounds would be separated and clustered among their own review questions. This allows an easier viewing of different review rounds in order to determine how the class improved. The data passed to the _team_charts.html.erb view file contains all of the questions for all review rounds associated with the assignment.

===Class Performance===
The Class Performance visualization will allow the instructor to view a histogram of 0 to 5 scores for a particular assignment. Furthermore, the visualization will allow the user to switch between the preliminary submission and the final submission as well as view a combined view.

===Review Performance===
There some obsolete codes in review_mapping_helper.rb about Dr. Kidd's course. Those codes were intended to calculate author feedbacks of reviews and there are also some related codes in _review_report.html.erb. However, in the view part, those codes are commented and those do not work. In fact, Dr. Kidd's course is 806, which is not on Expertiza now. So those obsolete codes are removed. Since in the testing files there are no corresponding codes for those parts, the previous tests still work.
The new review table allows the instructor to sort the result by more options, like the number of reviews completed, the average volume and the average score.
[[File:VirtualBox_Expertiza_Development_1_1_28_04_2018_23_24_38.png]]

== Pending Tasks ==

Currently our project is not complete end to end. It is our hope to complete various aspects in order have a more fruitful demo. That being said, the visualization changes are currently suffering difficulties in data formatting. For that task the front end is already complete as can be seen above.

== References ==
Here is our project [https://github.com/aspandit/expertiza repo] <br />
Here is our created [https://github.com/expertiza/expertiza/pull/1167 Pull Request]

File:VirtualBox Expertiza Development 1 1 28 04 2018 23 24 38.png

2018-04-29T03:42:13Z

Mpan2:

CSC/ECE 517 Spring 2018- Project E1816: Visualization for Instructors

CSC/ECE 517 Spring 2018 E1816 mpan2

2018-04-06T05:05:13Z

Mpan2: /* Files Involved */

CSC/ECE 517 Spring 2018 E1812

2018-04-06T05:04:34Z

Mpan2:

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
The project aims to write a unit test for on_the_fly_calc.rb. This model file provides a module for assignments to calculate different kinds of scores when loading the views. However, there was no corresponding unit test and the coverage was only 15.45% after running all test cases.
===Test Driven-Development===
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,but more recently has created more general interest in its own right.
The TDD sequence can be can be summarized in following steps.

1.Add a Test:

TDD begins by writing succinct test cases to test each of the features. This is opposite to traditional software development paradigm where code is written first and then test cases are later written to test the application.

2.Run all tests and see if the new test fails:

This step validates that the test harness is working correctly, shows that the new test does not pass without requiring new code because the required behavior already exists, and it rules out the possibility that the new test is flawed and will always pass. The new test should fail for the expected reason. This step increases the developer's confidence in the new test.

3.Write the code:

The next step is to write the minimum amount of code that causes the test case to pass.

4.Run tests:

In this steps the test cases are run.If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.

5. Refactor code:

In this step, refactoring of code is performed by following good design principles like removal of duplicate code, improving the readability and maintainability of the code.

6. Repeat:

Starting with another new test,the next step is to repeat the cycle to push the functionality forward.

Advantages of using TDD:
*Narrowing Problem Focus
*Tidier Code
*Not worrying about dependencies
*Easier refactoring
*Better Test coverage and fewer bugs

===Unit Testing===
[https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code are tested to catch errors early in the development process. For a model it involves testing the interface and on how it responds to commands and queries from outside. Model testing is bounded to the functionality of only the model under test and doesn't test how its collaborating models get affected based on this query.

Unit Testing provides several benefits which can be summarized in the below points.

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.
==Problem Statement==
There is no corresponding unit test for on_the_fly_calc.rb. The OnTheFlyCal module provides 4 publish methods for assignments: compute_total_score, compute_reviews_hash, compute_avg_and_ranges_hash and scores. We need to test all those methods. Privately methods are tested when testing public methods instead of tested directly.
===Files Involved===
The files to be understood and created are:

1. app/models/on_the_fly_calc.rb

2. spec/models/on_the_fly_calc_spec.rb
===Team Members===
1. Dileep Badveli (dbadvel@ncsu.edu)

2. Minghao Pan (mpan2@ncsu.edu)

==Plan of Work==
The task is to write test cases for testing the on_the_fly_calc model file. There was no Rspec file for the corresponding model exists so we need to create a new file and build tests from scratch. For this purpose different sub-tasks involved

1. Setting up the Expertiza environment;

2. Understand the functionality of model file in on_the_fly_calc.rb;

3. Understand the linked data attributes and methods being used;

4. Creating stub entries for testing different methods;

5. Writing testing conditions for different methods and compare with the expected outputs.
Objects were created using structures left in the factory file when needed. An example of this is let(:questionnaire) { create(:questionnaire, id: 1)}.
After developing different objects by this method, the objects get used in test cases to either avoid the implementation of the methods specified in the model or make it return a value which can be used to test if conditions.

==Implementation Steps==
===Expertiza Environment Setup===

We used the Ubuntu-Expertiza image to setup the environment. We forked the master from Expertiza, cloned that and then run through the command terminal.

cd/expertiza/app/models

The on_the_fly_calc.rb model file is present in this directory.

=== Functionality of OnTheFlyCalc model ===
The OnTheFlyCal model is a module for the Assignment Class to calculate scores. Here are methods provided by this module:

The compute_total_score method is to compute the total score of a given assignment. The method collects all questionnaires of the assignment and calls the get_weighted_score method of Questionnaire Class to calculate the total score.

The get_weighted_score checks the round which the assignment questionnaire has been used and calls the compute_weighted_score method to finish the calculation. As for the symbol, if the questionnaire has never been used, the compute_weight_score just takes the symbol of the questionnaire; if the questionnaire has been used, the symbol is the symbol of the questionnaire plus the round. The compute_weighted_score method takes the symbol and the score to complete the final calculation. The method uses the raw average scores times the weight of the questionnaire and divides by 100.0. If the raw average is nil, it returns zero. The compute_reviews_hash method returns the hash of reviewers. First, the method will check whether the assignment varies rubrics by round and deal with the two cases separately. This procedure is also shared by the compute_avg_and_ranges_hash and scores methods because the difference between those two situations is critical. The class method varying_rubrics_by_round? of the assignment is essential. It searches for assignment_questionnaires which have been used in 2 rounds with for the current assignment. If no assignment questionnaire meets the conditions, it returns false.

For both cases, the hash of reviewers are generated with private methods and the raw score is rounded. If the assignment varies rubrics by round, every round will be included.
The compute_avg_and_ranges_hash method calculates the average scores, the range of scores and their corresponding hashes. Using the built-in method review_questionnaire_id, it collects review questions and finds questions. The compute_scores method of answer model is called to calculate the maximum, minimum and average of scores. Similar to the get_weighted_score method, if the assignment varies rubrics by round, every round is included.

The last method score calculates scores of a question. It calls private methods score_assignment and participant_score to obtain hashes of teams and participants. Like previous methods, it deals with two cases. If varying_rubrics_by_round? is true, it calls another three private methods to calculate the number of rounds, the average, and range of assessments and scores. If it does not vary, assessments and scores are obtained with the built-in method get_assessments_for of ReviewResponseMap and compute_scores of Answer. That is the general function of the OnTheFlyCalc module.

=== Test Entries Creation ===

Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

For most tests, there is no difference between build and create. Usually build is faster because it stores objects in the memory. However, in this case, create is preferred because we need to create the object in the database. During the test, sometimes we cannot find the object in the database if we use build rather than create.
We create two assignments whose assignment_questionnaires have been used in 1 and 2 rounds. That is for different cases of varying_rubrics_by_round?.

=== Testing Conditions ===
The varying_rubrics_by_round? has been called on self for each method except compute_total_score. Through the pattern of varying_rubrics_by_round? being used as an if statement, test cases have been made for the behaviors if it returns true and false.

For the compute_reviews_hash method located in the model,varying_rubrics_by_round? method called on an Assignment object will return true when multiple review phases with different review rubrics exist. Creating test examples which return true and false for the method call varying_rubrics_by_round? let the right behavior be tested. When it returns true scores_varying_rubrics behavior would have been accepted, while when return false scores_non_varying_rubrics behavior will occur.

For the compute_avg_and_ranges_hash method, the get_assessments_for method of ReviewResponseMap and compute_scores of Answer are tested for both cases. The assignment_teams are also tested. For varying_rubrics_by_round case, the review_questionnaire_id method of Assignment is tested.

For the last method score, the majority of the method is included in private methods. For the varying_rubrics_by_round case, we tested the built-in calculate_score method of Assignment.

==Conclusion and Learning Outcomes==
After writing the unit test we managed to increase the coverage of our rails application.
The difficulty of the test is that it involves lots of different classes and methods from different classes. A four-fold hash is used to denote the score. It is not straightforward to create assignments with all necessary attributes and other related objects.

==Github Page==
https://github.com/DileepBadveli/expertiza/blob/master/spec/models/on_the_fly_calc_spec.rb

==Reference==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1816 mpan2

2018-04-06T05:04:12Z

Mpan2: /* Expertiza Environment Setup */

CSC/ECE 517 Spring 2018 E1816 mpan2

2018-04-06T05:01:57Z

Mpan2: /* Expertiza */

CSC/ECE 517 Spring 2018 E1816 mpan2

2018-04-06T05:01:19Z

Mpan2: Created page with "==Introduction== ===Expertiza=== ==Problem Statement== ===Files Involved=== ===Team Members=== ===Plan of Work=== ==Implementation Steps== ===Expertiza Environment Setup=== ===Fu..."

==Introduction==
===Expertiza===
==Problem Statement==
===Files Involved===
===Team Members===
===Plan of Work===
==Implementation Steps==
===Expertiza Environment Setup===
===Functionality===
==Conclusion==
==References==

CSC/ECE 517 Spring 2018 E1812

2018-04-03T02:01:54Z

Mpan2: /* Conclusions */

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
The project aims to write a unit test for on_the_fly_calc.rb. This model file provides a module for assignments to calculate different kinds of scores when loading the views. However, there was no corresponding unit test and the coverage was only 15.45% after running all test cases.
===Test Driven-Development===
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,but more recently has created more general interest in its own right.
The TDD sequence can be can be summarized in following steps.

1.Add a Test:

TDD begins by writing succinct test cases to test each of the features. This is opposite to traditional software development paradigm where code is written first and then test cases are later written to test the application.

2.Run all tests and see if the new test fails:

This step validates that the test harness is working correctly, shows that the new test does not pass without requiring new code because the required behavior already exists, and it rules out the possibility that the new test is flawed and will always pass. The new test should fail for the expected reason. This step increases the developer's confidence in the new test.

3.Write the code:

The next step is to write the minimum amount of code that causes the test case to pass.

4.Run tests:

In this steps the test cases are run.If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.

5. Refactor code:

In this step, refactoring of code is performed by following good design principles like removal of duplicate code, improving the readability and maintainability of the code.

6. Repeat:

Starting with another new test,the next step is to repeat the cycle to push the functionality forward.

Advantages of using TDD:
*Narrowing Problem Focus
*Tidier Code
*Not worrying about dependencies
*Easier refactoring
*Better Test coverage and fewer bugs

===Unit Testing===
[https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code are tested to catch errors early in the development process. For a model it involves testing the interface and on how it responds to commands and queries from outside. Model testing is bounded to the functionality of only the model under test and doesn't test how its collaborating models get affected based on this query.

Unit Testing provides several benefits which can be summarized in the below points.

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.
==Problem Statement==
There is no corresponding unit test for on_the_fly_calc.rb. The OnTheFlyCal module provides 4 publish methods for assignments: compute_total_score, compute_reviews_hash, compute_avg_and_ranges_hash and scores. We need to test all those methods. Privately methods are tested when testing public methods instead of tested directly.
===Files Involved===
The files to be understood and created are:

1. app/models/on_the_fly_calc.rb

2. spec/models/on_the_fly_calc_spec.rb
===Team Members===
1. Dileep Badveli (dbadvel@ncsu.edu)

2. Minghao Pan (mpan2@ncsu.edu)

==Plan of Work==
The task is to write test cases for testing the on_the_fly_calc model file. There was no Rspec file for the corresponding model exists so we need to create a new file and build tests from scratch. For this purpose different sub-tasks involved

1. Setting up the Expertiza environment;

2. Understand the functionality of model file in on_the_fly_calc.rb;

3. Understand the linked data attributes and methods being used;

4. Creating stub entries for testing different methods;

5. Writing testing conditions for different methods and compare with the expected outputs.
Objects were created using structures left in the factory file when needed. An example of this is let(:questionnaire) { create(:questionnaire, id: 1)}.
After developing different objects by this method, the objects get used in test cases to either avoid the implementation of the methods specified in the model or make it return a value which can be used to test if conditions.

==Implementation Steps==
===Expertiza Environment Setup===

We used the Ubuntu-Expertiza image to setup the environment. We forked the master from Expertiza, cloned that and then run through the command terminal.

cd/expetiza/app/models

The on_the_fly_calc.rb model file is present in this directory.

=== Functionality of OnTheFlyCalc model ===
The OnTheFlyCal model is a module for the Assignment Class to calculate scores. Here are methods provided by this module:

The compute_total_score method is to compute the total score of a given assignment. The method collects all questionnaires of the assignment and calls the get_weighted_score method of Questionnaire Class to calculate the total score.

The get_weighted_score checks the round which the assignment questionnaire has been used and calls the compute_weighted_score method to finish the calculation. As for the symbol, if the questionnaire has never been used, the compute_weight_score just takes the symbol of the questionnaire; if the questionnaire has been used, the symbol is the symbol of the questionnaire plus the round. The compute_weighted_score method takes the symbol and the score to complete the final calculation. The method uses the raw average scores times the weight of the questionnaire and divides by 100.0. If the raw average is nil, it returns zero. The compute_reviews_hash method returns the hash of reviewers. First, the method will check whether the assignment varies rubrics by round and deal with the two cases separately. This procedure is also shared by the compute_avg_and_ranges_hash and scores methods because the difference between those two situations is critical. The class method varying_rubrics_by_round? of the assignment is essential. It searches for assignment_questionnaires which have been used in 2 rounds with for the current assignment. If no assignment questionnaire meets the conditions, it returns false.

For both cases, the hash of reviewers are generated with private methods and the raw score is rounded. If the assignment varies rubrics by round, every round will be included.
The compute_avg_and_ranges_hash method calculates the average scores, the range of scores and their corresponding hashes. Using the built-in method review_questionnaire_id, it collects review questions and finds questions. The compute_scores method of answer model is called to calculate the maximum, minimum and average of scores. Similar to the get_weighted_score method, if the assignment varies rubrics by round, every round is included.

The last method score calculates scores of a question. It calls private methods score_assignment and participant_score to obtain hashes of teams and participants. Like previous methods, it deals with two cases. If varying_rubrics_by_round? is true, it calls another three private methods to calculate the number of rounds, the average, and range of assessments and scores. If it does not vary, assessments and scores are obtained with the built-in method get_assessments_for of ReviewResponseMap and compute_scores of Answer. That is the general function of the OnTheFlyCalc module.

=== Test Entries Creation ===

Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

For most tests, there is no difference between build and create. Usually build is faster because it stores objects in the memory. However, in this case, create is preferred because we need to create the object in the database. During the test, sometimes we cannot find the object in the database if we use build rather than create.
We create two assignments whose assignment_questionnaires have been used in 1 and 2 rounds. That is for different cases of varying_rubrics_by_round?.

=== Testing Conditions ===
The varying_rubrics_by_round? has been called on self for each method except compute_total_score. Through the pattern of varying_rubrics_by_round? being used as an if statement, test cases have been made for the behaviors if it returns true and false.

For the compute_reviews_hash method located in the model,varying_rubrics_by_round? method called on an Assignment object will return true when multiple review phases with different review rubrics exist. Creating test examples which return true and false for the method call varying_rubrics_by_round? let the right behavior be tested. When it returns true scores_varying_rubrics behavior would have been accepted, while when return false scores_non_varying_rubrics behavior will occur.

For the compute_avg_and_ranges_hash method, the get_assessments_for method of ReviewResponseMap and compute_scores of Answer are tested for both cases. The assignment_teams are also tested. For varying_rubrics_by_round case, the review_questionnaire_id method of Assignment is tested.

For the last method score, the majority of the method is included in private methods. For the varying_rubrics_by_round case, we tested the built-in calculate_score method of Assignment.

==Conclusion and Learning Outcomes==
After writing the unit test we managed to increase the coverage of our rails application.
The difficulty of the test is that it involves lots of different classes and methods from different classes. A four-fold hash is used to denote the score. It is not straightforward to create assignments with all necessary attributes and other related objects.

==Github Page==
https://github.com/DileepBadveli/expertiza/blob/master/spec/models/on_the_fly_calc_spec.rb

==Reference==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1812

2018-04-03T01:56:22Z

Mpan2: /* Implementation Steps */

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
The project aims to write a unit test for on_the_fly_calc.rb. This model file provides a module for assignments to calculate different kinds of scores when loading the views. However, there was no corresponding unit test and the coverage was only 15.45% after running all test cases.
===Test Driven-Development===
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,but more recently has created more general interest in its own right.
The TDD sequence can be can be summarized in following steps.

1.Add a Test:

TDD begins by writing succinct test cases to test each of the features. This is opposite to traditional software development paradigm where code is written first and then test cases are later written to test the application.

2.Run all tests and see if the new test fails:

This step validates that the test harness is working correctly, shows that the new test does not pass without requiring new code because the required behavior already exists, and it rules out the possibility that the new test is flawed and will always pass. The new test should fail for the expected reason. This step increases the developer's confidence in the new test.

3.Write the code:

The next step is to write the minimum amount of code that causes the test case to pass.

4.Run tests:

In this steps the test cases are run.If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.

5. Refactor code:

In this step, refactoring of code is performed by following good design principles like removal of duplicate code, improving the readability and maintainability of the code.

6. Repeat:

Starting with another new test,the next step is to repeat the cycle to push the functionality forward.

Advantages of using TDD:
*Narrowing Problem Focus
*Tidier Code
*Not worrying about dependencies
*Easier refactoring
*Better Test coverage and fewer bugs

===Unit Testing===
[https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code are tested to catch errors early in the development process. For a model it involves testing the interface and on how it responds to commands and queries from outside. Model testing is bounded to the functionality of only the model under test and doesn't test how its collaborating models get affected based on this query.

Unit Testing provides several benefits which can be summarized in the below points.

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.
==Problem Statement==
There is no corresponding unit test for on_the_fly_calc.rb. The OnTheFlyCal module provides 4 publish methods for assignments: compute_total_score, compute_reviews_hash, compute_avg_and_ranges_hash and scores. We need to test all those methods. Privately methods are tested when testing public methods instead of tested directly.
===Files Involved===
The files to be understood and created are:

1. app/models/on_the_fly_calc.rb

2. spec/models/on_the_fly_calc_spec.rb
===Team Members===
1. Dileep Badveli (dbadvel@ncsu.edu)

2. Minghao Pan (mpan2@ncsu.edu)

==Plan of Work==
The task is to write test cases for testing the on_the_fly_calc model file. There was no Rspec file for the corresponding model exists so we need to create a new file and build tests from scratch. For this purpose different sub-tasks involved

1. Setting up the Expertiza environment;

2. Understand the functionality of model file in on_the_fly_calc.rb;

3. Understand the linked data attributes and methods being used;

4. Creating stub entries for testing different methods;

5. Writing testing conditions for different methods and compare with the expected outputs.
Objects were created using structures left in the factory file when needed. An example of this is let(:questionnaire) { create(:questionnaire, id: 1)}.
After developing different objects by this method, the objects get used in test cases to either avoid the implementation of the methods specified in the model or make it return a value which can be used to test if conditions.

==Implementation Steps==
===Expertiza Environment Setup===

We used the Ubuntu-Expertiza image to setup the environment. We forked the master from Expertiza, cloned that and then run through the command terminal.

cd/expetiza/app/models

The on_the_fly_calc.rb model file is present in this directory.

=== Functionality of OnTheFlyCalc model ===
The OnTheFlyCal model is a module for the Assignment Class to calculate scores. Here are methods provided by this module:

The compute_total_score method is to compute the total score of a given assignment. The method collects all questionnaires of the assignment and calls the get_weighted_score method of Questionnaire Class to calculate the total score.

The get_weighted_score checks the round which the assignment questionnaire has been used and calls the compute_weighted_score method to finish the calculation. As for the symbol, if the questionnaire has never been used, the compute_weight_score just takes the symbol of the questionnaire; if the questionnaire has been used, the symbol is the symbol of the questionnaire plus the round. The compute_weighted_score method takes the symbol and the score to complete the final calculation. The method uses the raw average scores times the weight of the questionnaire and divides by 100.0. If the raw average is nil, it returns zero. The compute_reviews_hash method returns the hash of reviewers. First, the method will check whether the assignment varies rubrics by round and deal with the two cases separately. This procedure is also shared by the compute_avg_and_ranges_hash and scores methods because the difference between those two situations is critical. The class method varying_rubrics_by_round? of the assignment is essential. It searches for assignment_questionnaires which have been used in 2 rounds with for the current assignment. If no assignment questionnaire meets the conditions, it returns false.

For both cases, the hash of reviewers are generated with private methods and the raw score is rounded. If the assignment varies rubrics by round, every round will be included.
The compute_avg_and_ranges_hash method calculates the average scores, the range of scores and their corresponding hashes. Using the built-in method review_questionnaire_id, it collects review questions and finds questions. The compute_scores method of answer model is called to calculate the maximum, minimum and average of scores. Similar to the get_weighted_score method, if the assignment varies rubrics by round, every round is included.

The last method score calculates scores of a question. It calls private methods score_assignment and participant_score to obtain hashes of teams and participants. Like previous methods, it deals with two cases. If varying_rubrics_by_round? is true, it calls another three private methods to calculate the number of rounds, the average, and range of assessments and scores. If it does not vary, assessments and scores are obtained with the built-in method get_assessments_for of ReviewResponseMap and compute_scores of Answer. That is the general function of the OnTheFlyCalc module.

=== Test Entries Creation ===

Mock/dummy objects are needed to be created for any unit testing criteria.These objects are loaded freshly and deleted after every testing condition.

For most tests, there is no difference between build and create. Usually build is faster because it stores objects in the memory. However, in this case, create is preferred because we need to create the object in the database. During the test, sometimes we cannot find the object in the database if we use build rather than create.
We create two assignments whose assignment_questionnaires have been used in 1 and 2 rounds. That is for different cases of varying_rubrics_by_round?.

=== Testing Conditions ===
The varying_rubrics_by_round? has been called on self for each method except compute_total_score. Through the pattern of varying_rubrics_by_round? being used as an if statement, test cases have been made for the behaviors if it returns true and false.

For the compute_reviews_hash method located in the model,varying_rubrics_by_round? method called on an Assignment object will return true when multiple review phases with different review rubrics exist. Creating test examples which return true and false for the method call varying_rubrics_by_round? let the right behavior be tested. When it returns true scores_varying_rubrics behavior would have been accepted, while when return false scores_non_varying_rubrics behavior will occur.

For the compute_avg_and_ranges_hash method, the get_assessments_for method of ReviewResponseMap and compute_scores of Answer are tested for both cases. The assignment_teams are also tested. For varying_rubrics_by_round case, the review_questionnaire_id method of Assignment is tested.

For the last method score, the majority of the method is included in private methods. For the varying_rubrics_by_round case, we tested the built-in calculate_score method of Assignment.

==Conclusions==
==Github Page==
https://github.com/DileepBadveli/expertiza/blob/master/spec/models/on_the_fly_calc_spec.rb

==Reference==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1812

2018-04-03T01:52:47Z

Mpan2: /* Implementation Steps */

==Introduction==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework, supported by the National Science Foundation.
It is a place where students can submit and peer-review learning objects (assignments, codes, write ups, websites, etc). For an instructor, expertiza allows to create and customize new or existing assignments. For students, it allows to create and work on various projects and assignments. It provides a platform to peer review other students' submissions across various document types, including the URLs and wiki pages.
The project aims to write a unit test for on_the_fly_calc.rb. This model file provides a module for assignments to calculate different kinds of scores when loading the views. However, there was no corresponding unit test and the coverage was only 15.45% after running all test cases.
===Test Driven-Development===
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,but more recently has created more general interest in its own right.
The TDD sequence can be can be summarized in following steps.

1.Add a Test:

TDD begins by writing succinct test cases to test each of the features. This is opposite to traditional software development paradigm where code is written first and then test cases are later written to test the application.

2.Run all tests and see if the new test fails:

This step validates that the test harness is working correctly, shows that the new test does not pass without requiring new code because the required behavior already exists, and it rules out the possibility that the new test is flawed and will always pass. The new test should fail for the expected reason. This step increases the developer's confidence in the new test.

3.Write the code:

The next step is to write the minimum amount of code that causes the test case to pass.

4.Run tests:

In this steps the test cases are run.If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.

5. Refactor code:

In this step, refactoring of code is performed by following good design principles like removal of duplicate code, improving the readability and maintainability of the code.

6. Repeat:

Starting with another new test,the next step is to repeat the cycle to push the functionality forward.

Advantages of using TDD:
*Narrowing Problem Focus
*Tidier Code
*Not worrying about dependencies
*Easier refactoring
*Better Test coverage and fewer bugs

===Unit Testing===
[https://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a software testing method by which individual units of source code are tested to catch errors early in the development process. For a model it involves testing the interface and on how it responds to commands and queries from outside. Model testing is bounded to the functionality of only the model under test and doesn't test how its collaborating models get affected based on this query.

Unit Testing provides several benefits which can be summarized in the below points.

1. Finds problems early:

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
In test-driven development (TDD), which is frequently used in both extreme programming and scrum, unit tests are created before the code itself is written. When the tests pass, that code is considered complete.

2. Facilitates change:

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.

3. Simplifies Integration:

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

4. Documentation:

Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface's API.

5. Design:

When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test is passing, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.
==Problem Statement==
There is no corresponding unit test for on_the_fly_calc.rb. The OnTheFlyCal module provides 4 publish methods for assignments: compute_total_score, compute_reviews_hash, compute_avg_and_ranges_hash and scores. We need to test all those methods. Privately methods are tested when testing public methods instead of tested directly.
===Files Involved===
The files to be understood and created are:

1. app/models/on_the_fly_calc.rb

2. spec/models/on_the_fly_calc_spec.rb
===Team Members===
1. Dileep Badveli (dbadvel@ncsu.edu)

2. Minghao Pan (mpan2@ncsu.edu)

==Plan of Work==
The task is to write test cases for testing the on_the_fly_calc model file. There was no Rspec file for the corresponding model exists so we need to create a new file and build tests from scratch. For this purpose different sub-tasks involved

1. Setting up the Expertiza environment;

2. Understand the functionality of model file in on_the_fly_calc.rb;

3. Understand the linked data attributes and methods being used;

4. Creating stub entries for testing different methods;

5. Writing testing conditions for different methods and compare with the expected outputs.
Objects were created using structures left in the factory file when needed. An example of this is let(:questionnaire) { create(:questionnaire, id: 1)}.
After developing different objects by this method, the objects get used in test cases to either avoid the implementation of the methods specified in the model or make it return a value which can be used to test if conditions.

==Implementation Steps==
===Expertiza Environment Setup===

We used the Ubuntu-Expertiza image to setup the environment. We forked the master from Expertiza, cloned that and then run through the command terminal.

cd/expetiza/app/models

The on_the_fly_calc.rb model file is present in this directory.

=== Functionality of OnTheFlyCalc model ===
The OnTheFlyCal model is a module for the Assignment Class to calculate scores. Here are methods provided by this module:

The compute_total_score method is to compute the total score of a given assignment. The method collects all questionnaires of the assignment and calls the get_weighted_score method of Questionnaire Class to calculate the total score.

The get_weighted_score checks the round which the assignment questionnaire has been used and calls the compute_weighted_score method to finish the calculation. As for the symbol, if the questionnaire has never been used, the compute_weight_score just takes the symbol of the questionnaire; if the questionnaire has been used, the symbol is the symbol of the questionnaire plus the round. The compute_weighted_score method takes the symbol and the score to complete the final calculation. The method uses the raw average scores times the weight of the questionnaire and divides by 100.0. If the raw average is nil, it returns zero. The compute_reviews_hash method returns the hash of reviewers. First, the method will check whether the assignment varies rubrics by round and deal with the two cases separately. This procedure is also shared by the compute_avg_and_ranges_hash and scores methods because the difference between those two situations is critical. The class method varying_rubrics_by_round? of the assignment is essential. It searches for assignment_questionnaires which have been used in 2 rounds with for the current assignment. If no assignment questionnaire meets the conditions, it returns false.

For both cases, the hash of reviewers are generated with private methods and the raw score is rounded. If the assignment varies rubrics by round, every round will be included.
The compute_avg_and_ranges_hash method calculates the average scores, the range of scores and their corresponding hashes. Using the built-in method review_questionnaire_id, it collects review questions and finds questions. The compute_scores method of answer model is called to calculate the maximum, minimum and average of scores. Similar to the get_weighted_score method, if the assignment varies rubrics by round, every round is included.

The last method score calculates scores of a question. It calls private methods score_assignment and participant_score to obtain hashes of teams and participants. Like previous methods, it deals with two cases. If varying_rubrics_by_round? is true, it calls another three private methods to calculate the number of rounds, the average, and range of assessments and scores. If it does not vary, assessments and scores are obtained with the built-in method get_assessments_for of ReviewResponseMap and compute_scores of Answer. That is the general function of the OnTheFlyCalc module.

==Conclusions==
==Github Page==
https://github.com/DileepBadveli/expertiza/blob/master/spec/models/on_the_fly_calc_spec.rb

==Reference==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]

CSC/ECE 517 Spring 2018 E1812

2018-04-03T01:49:16Z

Mpan2: /* Implementation Steps */

2018-04-03T00:49:56Z

Mpan2:

2018-03-26T20:15:52Z

Mpan2:

CSC/ECE 517 Spring 2018 E1812

2018-03-26T19:56:28Z

Mpan2: /* Description of the the module */

CSC/ECE 517 Spring 2018 E1812

2018-03-26T19:56:15Z

Mpan2: /* Description of the the module */