CSC/ECE 517 Spring 2023 - E2305. Grading audit trail
Team Introduction
Team Member
Sarika Vishwanatham (svishwa2@ncsu.edu)
Chetana Chunduru (cchetan2@ncsu.edu)
Shreya Buddaiahgari (sbuddai@ncsu.edu)
Mentor
Krishna Saurabh Vankadaru (kvankad@ncsu.edu)
Problem Description
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:
1. The identity of the person who assigned the grade and the time it was completed must be stated.
2. Previous feedback from other instructors must also be kept. Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.
There are now two places where grading audit trails need to be added:
1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View
2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries
Prior Work
In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.
They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.
- Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.
- Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database
- View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.
Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.
Files Modified By Previous Team
- \app\controllers\grades_controller.rb
- \app\controllers\grading_histories_controller.rb
- \app\controllers\review_mapping_controller.rb
- \app\helpers\grading_histories_helper.rb
- \app\models\grading_history.rb
- \app\models\review_grading_history.rb
- \app\models\submission_grading_history.rb
- \app\views\assignments\list_submissions.html.erb
- \app\views\grading_histories\index.html.erb
- \app\views\reports\_review_report.html.erb
- \config\routes.rb
- \app\views\assignments\list_submissions.html.erb
Testing By Previous Team
Functional tests were added.
functional tests added to these files : spec/controllers/review_mapping_controller_spec.rb : spec/models/grading_history.rb : spec/controllers/grading_history_controller.rb
A feature test ensuring that a submission's grading history is shown completely, and in chronological order, was added.
feature test handled by these two files : spec/features/grade_histories_spec.rb : spec/features/helpers/grade_histories_helper.rb
Issues with Existing Tests
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.
https://www.youtube.com/watch?v=yyxX_kRYxLc
General Design Plan
Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.
1. Review report was not generated previously due to an error, the issue fixture is taken care.
2. The table which was previously added to the database was not visible, now the table is added again (grading_history)
2. To correct build errors, manually cherry-pick and refine the changes from earlier iterations.
3. Make GUI clean so that it works well with the most recent Expertiza.
4. Provide test cases and comments.
Planned and Completed Work
General Design Goals
Changes to the Grading History Table
The images below reference grading history view issues mentioned above in the Problem Statement.
To DRY the code, we will remove the redundant table data boxed below...
...and we'll move it to the page header:
Behavior Driven Development
BDD Scenarios
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.
System Stability: Strategies
The source of crashing issues is currently unknown. To debug this, we will pursue the following:
- Refactor the specs and controllers
- Ensure DRY principle is followed
- Improve readability and maintainability
- Add code comments as needed
- Ensure testing objects do not cause crashes
Documentation
- Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
- Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
- A pull request of the fixed code, fully commented, will be provided in this document.
Implementation
Files added
1. grading_history table is created
