(no late submissions will be accepted)
After becoming an expert on the bugs from Homework 2 Part 1, it's time to squash those nasty critters once and for all! This assignment is the second of the two parts and will consist of the implementation portion for Homework 2.
This is a team-based assignment. Teams are the same in Homework 2 Part 2 as they were for Homework 2 Part 1.
The bugs for which you wrote GitHub issues in Homework 2 Part 1 are the bugs your team will fix. You must implement a valid fix for each bug. Once these bugs are fixed, the issues in the GitHub Issue Tracker should be closed.
Teams of size 2: You must fix three bugs
Teams of size 3: You must fix four bugs
Bug Summaries and links:
Bug #1: Full calendar crashes (note: handling the first part of the main flow UC40, "An LHCP or patient can click the “View Appointment Calendar” link to view his/her appointments in the current month displayed on a calendar for the current month [S1]", is sufficient in the fix) Bug Reports
Bug #2: View basic patient health issue Bug Reports
Bug #3: Read messages marked unread (Expected behavior: click on unread message, then press back button on browser. The message should be marked as read, like it is in Gmail on Chrome.) Bug Reports
Bug #4: No appointment made upon request Bug Reports
Bug #5: Multiple invalid login attempts issue Bug Reports
Bug #6: Editing personnel records issue Bug Reports
Extra Credit (limited to 1 additional bug per team):
1) If you wrote an extra credit GitHub issue and Cucumber tests for Homework 1 Part 1, you may fix that bug for 3 points extra credit in Homework 2 Part 2.
2) If you did not write an extra credit GitHub issue and Cucumber test for Homework 1 Part 1 and you are interested in extra credit on Homework 2 Part 2, you must write a GitHub issue, Cucumber tests, and fix an additional bug to receive 3 points extra credit on Homework 2 Part 2 (this allows traceability from issue to fix, as is needed to verify your fix).
For full points on the extra credit, information on the tests and bug must be included in Parts B and C of this assignment.
The tests written in Homework 2 Part 1 should pass now that the bugs have been fixed. If any other tests begin failing as a result of the fixed bugs, those tests need to be updated to pass.
All tests should be passing on Jenkins!
Jenkins master: go.ncsu.edu/jenkins-csc326
This wiki update is used to keep the management staff updated on the progress of a project. Create a new page in your team's wiki, title it "Homework 2 Report", and include the following information:
Problem Statement: A one or two paragraph description, using complete sentences and proper grammar, of the requirement modifications, additions, or enhancements. The problem statement should not include information about why the changes are made, but is an overview of the portion of iTrust that you are modifying. This is the introduction to the project document, and sets up the rest of information that the document conveys.
Planning Poker Estimates: Provide a listing of your planning poker estimates for the tasks associated with completing both parts of HW2. For Part 2, also include why these estimates were selected and the range of the original estimates.
Design Decisions: Describe the decisions that you made when refactoring and fixing bugs. This is a high level overview of the changes you’re making. Describe the changes at all layers of the system (JSP, Action, DAO, SQL). If you are not making any large changes, state why not. This section should explain the pieces in your design diagram that will be touched to implement the changes, the reasons for the changes, and the limitations and constraints of the design so that a project manager can evaluate the design’s goals and functionality and so that another programmer could implement the design without additional clarification by you.
Test Plan: Provide black box test information (using the four parts of a test case shown in the lecture slides - id, input, expected output, actual output) for each one of your Cucumber tests. These tests should be run manually. Provide details about how to start running iTrust and the files that will be used to generated your automated test inputs (as well as any clean up code).
File Change Description: File change justifications should appear in your commit history, not the condensed report. You must describe what you are changing for each of the following file types (JSP, Action, DAO, SQL) in commit messages. This in combination with the design decisions means that you could hand off this document to another programmer and they would be able to implement your design. This is a lower level discussion of design to implementation.
Each member of your team should evaluate every other member of your team. Submit your peer evaluations via CATME. The CATME system will email for your evaluations.
This assignment must be completed as a pair/team. Lack of participation by a partner/teammate may result in the adjustment of grades.
We expect that both partners will contribute to the assignment, which means that we expect to see at least one GitHub push for each person on the team. Those who do not participate in their homework may not receive full credit for the assignment. For example, if it is determined you did half the work you should have, your grade may be multiplied by 50%. A team member without a GitHub push will have an automatic deduction of 10 points. The exceptions to this are 1) a documented technology problem that prevents pushing to GitHub on personal AND lab machines (notification to the teaching staff must occur a least 24 hours BEFORE the deadline) and 2) documented pair programming on the assignment. Pair programming documentation should occur in the commit messages (please use unitIDs to identify the other member of the pair).
Submission
Submissions will be made through GitHub/Jenkins. This means that all commits and issues must be made by the deadline. Anything after the close of the deadline is counted as a late submission and will not be graded. There is nothing to submit to this Moodle assignment directly; graders will look at Jenkins and GitHub instead. Your Jenkins build must have a green ball to receive full credit.
Note: Feel free to start making changes and edits to your teams repo immediately. We will grade Homework 2 Part 1 based on the status of your repo when that assignment is due. That said, if you start working on Homework 2 Part 2 prior to the deadline for Part 1, it's recommended that you create a branch for Part 2 and merge it with master following the Part 1 deadline.
Part A: Bug Reporting (24 or 32 points)
Part B: Cucumber Tests (15 points - same for all teams)
Points
15 points
Item
All Cucumber tests pass.
Part C: Condensed Report to Management (10 points)
Part D: Peer Evaluation (5 points)
Total Points: 62 points for teams of size 3 (that means your grade will be divided by 62 to put it on a 100 point scale), or 54 points for teams of size 2 (that means your grade will be divided by 54 to put it on a 100 point scale). Extra credit points, if any, are added after conversion to the 100 point scale.