| CPSC 329 | Software Development | Fall 2026 |
In this (mostly) group project, you and a partner will extend the Hedgehogs in a Hurry game from project P0. This project has two parts:
Part B will be released after lab 6 on Tuesday 10/6.
Teams. You'll work in pairs, starting from both partners' P0 codebases. If your P0 isn't complete enough for your partner to work with, a reference implementation is available as a substitute (see A0). The teams will be the same pairs that have formed in lab: Jubayer and Andrae, William and Anik, Sebastian and Henry, Ainsley and Brooke.
Individual and team work.
Task A1 (seeded dice) is individual. The code and associated deliverables must be entirely your own work, though you may ask your partner questions about their code. No pair programming on A1!
Task A2 (code review) is also individual. Do this on your own, without help from your partner.
The rest of Part A and all of Part B are team tasks, though many of the deliverables are individual. The individual deliverables must be entirely your own work, while the code and team deliverables must be entirely your team's work.
No AI. Review the course AI policy for details.
Check-in meetings. Two short check-in meetings are required:
Drop in during office hours — no appointment is necessary unless you are unable to make any of the scheduled office hours.
The check-in meetings aren't graded; their purpose is to make sure your team is on track. At least one partner must attend each meeting and both are encouraged to attend. In addition, each partner must attend at least one of the two meetings, so if only one of you comes to the first check-in, the other must attend the second.
Hand-in meeting. A 20-minute individual hand-in meeting is required after handin of the whole project. These meetings will be scheduled before the due date and normally take place within a day or two of it. Be ready to walk through your own code and other deliverables. Also be ready to explain parts of your partner's work, and bigger-picture things like design decisions and your team's process. This isn't a quiz about content; it's to confirm that your handin reflects your own understanding and effort.
Due Monday 10/26 at the start of class. There is a single handin for both parts. Late handins are not accepted for projects, but an occasional 1-2 day extension is possible in case of a last-minute time crunch. (Plan ahead to avoid this!) See the late policy for details.
In Part A, you'll add reproducible dice rolls to the game, which is handy for testing. Read through this whole part (sections marked with "[A]" in the heading) to get an overview of what you'll be doing, then work through the five tasks in the Tasks section in order.
It can be useful for testing to be able to replay the same sequence of turns. Since the rest of the game is deterministic, this only requires being able to repeat the same sequence of dice rolls: with the same rolls and the same player input, the game plays out the same way.
Computers typically do not generate truly random numbers; instead a pseudorandom number generator produces a sequence of numbers that appears random but is completely determined by a starting value called the seed. Two generators created with the same seed produce the same sequence of numbers. In Java, new Random(seed) creates a generator with the specified seed.
While the same seed ensures the same sequence of values, ensuring the same sequence of dice rolls requires a few additional things:
All dice rolls come from a single generator. The generator is created once, with the game's seed, and every roll is drawn from it.
The dice generator is used only for dice rolls. Nothing else draws numbers from it.
Exactly one roll occurs per turn. The die is rolled once, at the start of each turn, regardless of what happens during the turn, including turns in which the forward move turns out to be impossible or where invalid input results in a reprompt.
If these conditions hold, a game can be replayed exactly by starting it with the same number of players, the same dice choice, and the same sequence of player moves.
Three dice roll options should be supported:
Random — the standard option, where a new sequence of dice rolls is used for each game. Print the seed needed to replay the game at the beginning and the end of the game.
Chosen seed — prompt for the desired seed on game startup. Any value that fits in a Java long (including negative values) is a valid seed. Print the seed at the beginning and the end of the game.
Dice script — prompt for a filename on game startup. Dice rolls are taken from the file, one per turn. If the script runs out of rolls before anyone has won, continue with a random seed and print a message to that effect.
There's no way to find out a Random object's seed once it has been constructed, so for random mode it is necessary to generate a seed first and then create the dice generator with that seed. An option here is to create a Random object with the default constructor and use that to generate a random value for the seed. Create a new Random object with the seed to use for dice rolls. Usability suggestion: seeds that are at most 7-8 digits long are much easier to read and type, so consider limiting the range of generated seeds.
Do these tasks in order.
This project starts with each partner working with the other's codebase before settling on one to continue with for the rest of the project.
Each partner, in your own P0 repository:
Establish a GitHub repository. Create a new private GitHub repository named hedgehogs and push your completed P0 main to it. If your P0 isn't complete enough to move forward with adding new features, a reference implementation is available as a substitute. In this case, create the GitHub repository, add me (sbridgeman) as a collaborator, and send me an email asking for the reference implementation. I'll push it to your repository.
Mark the end of P0. [Only if you are working with your own P0 — skip this step if you are using the reference implementation.] Create a tag named P0-handin on main to reflect the handin version of P0. Do this on GitHub: go to the repository's main page, locate "Create a new release" under the Releases heading on the righthand sidebar, choose "Create new tag" under "Tag: Select tag" and enter P0-handin, make sure that the target is main, enter a human-readable release title such as "hedgehogs P0 handin", and publish the release.
Add your partner and me (sbridgeman) as collaborators.
Each partner, in your partner's P0 repository:
Accept the collaborator invitation.
Check out (clone) your partner's repository as a new Eclipse project named hedgehogs-partner.
Make sure the Eclipse project is linked to main before proceeding — switch branches if necessary.
As a team:
Read through the Team Process section below together.
Hold your team kickoff meeting and record the results. Also start the team log with an entry for this meeting. For now, use Google Docs or similar collaborative tool; once you have chosen a codebase to work with in A3, copy them over into docs/team-kickoff.txt and docs/team-log.txt respectively.
This is an individual task — no pair programming! You may ask your partner questions about their code if there is something confusing, but not otherwise work together on this part.
Add the random and chosen seed options to your partner's P0 codebase (not your own!). To do this:
Project documents setup. Create a docs directory in the top level of your Eclipse project (at the same level as src, not inside src). This will hold various documents associated with the project.
Change impact analysis. Before writing any code, identify what will need to change to accommodate the new features. Write a short report addressing:
Remember the strategies discussed in class for understanding existing code. Hand the report in on Canvas (PDF) before writing any code.
Test plan. Working in the main branch, write a test plan for the new functionality in docs/A1-test-plan.txt. Commit and push when you are done.
Implement and test the new functionality, writing JUnit tests using the same standard as for project P0 — you can skip testing low-risk methods and may defer complex scenarios to manual testing, with a brief rationale in your test plan for any tests you don't implement. Remember the workflow: create a new branch for your work on this feature, commit to your local repository and push the branch to GitHub as appropriate, then open a pull request and merge the branch back into main on GitHub when you are done. You can delete the branch once the merge is successful.
Reflection. After merging, switch back to the main branch, copy your initial change impact analysis report into docs/A1-change-impact.txt, and add a short reflection (a few paragraphs) at the end. How does what you actually did compare to your initial analysis? What did you miss or what did you anticipate that didn't materialize? What can you take away to help you analyze changes more accurately next time? Commit and push when you are done.
Handin. Create a tag A1-handin on main (as you did in A0) to mark the end of A1 and to reflect your completed work on this task.
Note that all A1 deliverables (other than the initial change impact report submitted on Canvas) go into your partner's repository.
This is an individual task.
Review your partner's P0 codebase (including the seeded dice feature you just added). To do this:
Working in the main branch, create a document docs/A2-code-review.txt with your review report.
Look for problems in each of these categories:
Correctness — does the code do what it is supposed to? Look for robustness issues and weak defensive programming as well as bugs.
Standards — does naming, style, and formatting follow the coding standard? Is documentation (Javadoc) present and accurate?
Tests — is the program's behavior covered by meaningful tests, including edge and error cases? Identify important behavior that isn't tested.
Readability — could someone else (or you, in a few months) understand and modify this code? Look in particular for code smells — name each smell and give its location. (code smells reference — it is only required to consider the core smells, but you are encouraged to check for all of the ones listed)
Write up the most significant issues (up to six) in detail: where it is, what the problem is, and a suggested fix. (Use the code review used in lab 5 as an example for the format; "Smell" is only relevant for code smell issues.) List any other issues you notice along with a short one-line note for each naming the issue and identifying the location. Cover all four categories — if you don't find any issues in a particular category, say what you checked for. Also note what the code does well in each category. Keep your feedback specific, actionable, kind, and constructive — your partner will read it.
Commit and push to update the code review when you are done.
Handin. Create a tag A2-handin on main (as you did in A0) to mark the end of A2 and to reflect your completed work on this task.
This is a team task.
Choose a codebase. Based on the code reviews, your experiences adding the new features in A1, and completeness of the programs, decide together on which codebase to continue with.
The rest of these steps should be taken in the chosen codebase. Note: don't delete the other repository even though it won't be extended farther! It is an essential record of work from project P0 and tasks A1-A2.
Set up an Eclipse project. Check out (clone) the chosen repository as a new Eclipse project named hedgehogs-variants.
Copy the team kickoff and meeting log into the project. Working in the main branch, create files docs/team-kickoff.txt and docs/team-log.txt and copy the content over from the temporary versions you created in A0. Update these moving forward — don't forget to add on to the team log when you have meetings! Commit and push when you are done.
Document the codebase choice. Working in the main branch, write a short memo (a few paragraphs) explaining/justifying the choice of which codebase to use in docs/A3-codebase-decision.txt. Commit and push when you are done.
Plan and split the work identified in the code review: (see Planning and Splitting Work in the Team Process section)
Set up labels. Create the labels used in this project: refactoring, testing, deferred, size: S, size: M, size: L, and joint. (bug already exists by default.)
Define the tasks.
Create a milestone named "A3 Code Review". Keep the recommended check-in date for part A (see the Logistics section) in mind when choosing the target date for the milestone.
Create issues in the milestone for the following:
Autoformatting the whole codebase with the course's Eclipse formatter settings (set up in lab 1). Label: refactoring.
Bringing the codebase up to the course coding standard, including naming and Javadoc for all public classes and methods. Naming should follow Java standard conventions, with the one exception that a trailing underscore is allowed for instance variables. If there's lots to fix, split this into multiple issues by class (or a group of related classes). Label: refactoring
Each of the detailed findings (the six most significant issues) in the A2 review of the chosen codebase. Split any particularly large tasks into multiple issues so they can be shared. If both partners agree that a finding isn't actually a problem, still create the issue to document it but you can then immediately close the issue with a comment explaining why. Label: refactoring, bug, or testing depending on the category (standards/readability, correctness, or tests respectively)
As in lab 5, take the title and description of the issue from the code review. Include as much detail as the code review has in the issue description.
Create issues for the other findings in the A2 review of the chosen codebase as well as for bugs and any other things that get noticed as you go along. Assign an appropriate label (refactoring, bug, or testing) depending on the kind of issue. Add major bugs to the A3 Code Review milestone; for other issues, including minor bugs, add a deferred label instead of adding them to the milestone. (It's not required to fix these backlog issues, but they should stay on record as known problems — if you have time later, move them into the milestone and fix them.)
Estimate effort for each task, including assigning size labels and addressing differences in each partner's independent estimates as directed in Planning and Splitting Work. Be sure to do your own estimates and submit on Canvas as directed before discussing with your teammate! Put the plan summary in docs/A3-refactoring-plan.txt.
Assign owners. Decide on who owns each task as directed in Planning and Splitting Work. The max 40%/60% split refers to all of the team tasks in part A (A3 and A4). Be sure to record the assignment by updating each issue's assignee and to note each partner's point total in the plan summary.
Commit and push to update the plan summary when you are done.
Now do the work:
Handle issues. Each issue should be handled on its own branch and merged into main through a pull request when it is done (as was done in lab 5). See the Version Control section (under Team Process) for the full workflow — it is the same as in lab 5 except for the added step of merging main into the branch and resolving conflicts before opening a pull request.
Notes:
Follow a test early methodology (see the Team Process section).
Use Eclipse's refactoring tools when applicable. (see lab 5).
Order matters. Autoformatting changes nearly every file, likely causing conflicts with every other refactoring. Do it first and merge it before any other task begins; it can be done in a few minutes, together. Similarly, write Javadoc for a class as part of or after any refactorings that rename, move, or restructure its methods so the documentation describes the final code.
When you are done with an issue, remember to record the actual size of the task in the pull request description.
Reflect. Once all the issues in the milestone have been closed, add a brief reflection (a few sentences to a paragraph) in the plan summary (docs/A3-refactoring-plan.txt) comparing the S/M/L estimates to the recorded actual sizes — where were you off and did the differences discussion predict it? Commit and push to update the plan summary when you are done.
Handin. Create a tag A3-handin on main (as you did in A0) to mark the end of A3 and to reflect your completed work on this task.
This is a team task.
Add the dice script option to the chosen codebase. To do this:
Plan as described in Planning and Splitting Work in the Team Process section. Use the following task breakdown as a starting point — split, combine, or add to them as you see fit:
Decide on the format of the dice script file.
Extend the startup prompts to offer all three dice modes, including prompting for a script filename.
Implement reading the script file.
Implement rolling from a script, including continuing with a random seed if the script runs out.
Create sample scripts for testing.
Additional notes:
Name the milestone "A4 Scripted Dice" and keep the recommended check-in date for part A (see the Logistics section) in mind when choosing the target date for the milestone.
Label issues with their size as well as enhancement (new functionality), testing (testing-only issues), or bug (for bugs). Fix bugs related to the current issue as part of working on that issue. If you discover an unrelated major bug, open a new issue for it and add it to the milestone; label minor ones as deferred.
Do your own effort estimates and submit them on Canvas before discussing them with your teammate.
Don't forget the "agree on interfaces" step! The code that uses the rolls depends on what the script-reading code provides, for example.
Name the plan summary docs/A4-scripted-dice-plan.txt.
Deciding on the format of the dice script file is a design task — do this first and together (swarm). Document the decision in docs/A4-script-format.txt.
Implement and test each issue on its own branch following the workflow in the Version Control and Test Early sections (under Team Process). Before writing code for an issue, its owner adds a test plan for that issue to docs/A4-test-plan.txt. Use the same standard as for project P0 — you can skip testing low-risk methods and may defer complex scenarios to manual testing, with a brief rationale in your test plan for any tests you don't implement.
Reflect. Once all the issues in the milestone have been closed, add the reflection to the plan summary as described in Planning and Splitting Work. Commit and push when you are done.
Handin. Create a tag A4-handin on main (as you did in A0) to mark the end of A4 and to reflect your completed work on this task.
These are the end results your Part A work is assessed against (see Assessment). Team code is assessed according to ownership.
For the chosen codebase:
Reproducible dice rolls. The random, chosen seed, and dice script modes are supported as specified above and the three reproducibility conditions hold.
Dice scripts. Scripts in the format documented in docs/A4-script-format.txt are read correctly, and the sample scripts work as intended.
A playable game. The P1 features are judged on their own as much as possible, but P1 changes shouldn't break previously working functionality and, conversely, major problems from P0 that keep the game from being played through correctly must be fixed.
Robustness. Bad input (including invalid seeds and missing or invalid script files) is rejected with a clear message and a reprompt. The program doesn't crash if used incorrectly.
For the other codebase:
Reproducible dice rolls. The random and chosen seed modes are supported as specified above and the three reproducibility conditions hold.
Robustness. Bad input (including invalid seeds) is rejected with a clear message and a reprompt. The program doesn't crash if used incorrectly. Only the A1 changes are assessed here; problems in the original P0 code don't count against the A1 work.
For the chosen codebase:
Coding standards followed — autoformatted with the course's Eclipse formatter settings, standard Java naming conventions (a trailing underscore on instance variables is allowed, but must be used consistently), meaningful names, Javadoc for every public class and method.
Code review addressed. Each of the detailed findings from the A2 review of the chosen codebase has been resolved: either fixed, or its issue closed with an explanation of why it isn't actually a problem. Other issues are recorded as issues, fixed or labeled deferred. New code doesn't reintroduce problems identified in the review.
Defensive programming and exceptions. User input and script file contents are validated, and checked exceptions are handled meaningfully (no empty catch blocks, and no catching Exception in general).
Tests. All JUnit tests pass on main. New functionality has tests as described in its test plan, with a rationale for any tests skipped or deferred to manual testing.
For the other codebase:
A1 code follows the coding standard, and has tests as described in the A1 test plan.
Follow the steps in each task and the practices in the Team Process section.
Sequencing. Each deliverable is created at the point specified — in particular, the change impact analysis before any A1 code, test plans before the code they cover, and independent estimates before task sizes and owners are assigned.
GitHub flow. All code changes are made on branches and merged through pull requests after main has been merged into the branch, main always passes all tests, and commits are incremental with meaningful messages.
Test early. Test plans are written before the code they cover and code that isn't covered by tests gets tests for its current behavior before it is refactored.
Planning and ownership. Each planned task is an issue in the milestone with a size label and an owner, each partner's share is within 40–60% across A3 and A4, plan summaries are complete, and actual sizes are recorded in pull request descriptions.
Team meetings and records. Meetings happen as your team agreed and the team log is kept up to date (with date, attendees, decisions, and open questions for each meeting). Decisions affecting the project are recorded in the log or in issues.
Part B will be added after lab 6 on Tuesday 10/6.
These practices apply to all team tasks in both parts; the Version Control and Test Early practices also apply to A1.
As part of A0, discuss the following and record notes in a shared document in Google Docs (or similar). Once you've chosen a codebase to work with in A3, move the document to the file docs/team-kickoff.txt.
Availability. When is each of you realistically available to work on the project, and when not? Include known busy periods during the project, such as exams, other project deadlines, travel, athletics, or work shifts.
Standing meetings. Pick two regular weekly meeting times (in person or online) that you'll both keep for the whole project. These can be brief meetings, but they shouldn't be skipped. Put them in your calendars now.
Communication. Which channel will you use (email, text, ...) and when do you each typically check it?
Work habits. Do you tend to start early or work close to deadlines? Do you prefer long sessions or short ones? Differences are fine; knowing about them lets you plan around them.
Review turnaround. (for part B) How soon after a pull request is opened will it be reviewed? Pick a time that fits both of your schedules but no more than 48 hours.
Goals. What does each of you want to get out of this project? What would a successful outcome look like to you? Are there skills or parts of the work you especially want experience with, or feel less confident about? This can help you split tasks.
Meet at least twice a week; short check-ins are fine.
Keep a running log of meetings in docs/team-log.txt. (Until you've chosen a codebase in A3, use a shared document in Google Docs or similar.) Each entry should have the date, who attended, the decisions made, and open questions. From A3 on, when new tasks are identified, create issues in GitHub and reference them in the log entry (e.g. "created #14-16; moved target date on #9"). Note that issues can include non-code tasks too, such as "write codebase decision memo", "submit individual effort estimates", or "schedule check-in meeting".
Day-to-day coordination happens in the channel chosen in your team kickoff (email, text, etc). This is for quick back-and-forth; anything decided that affects the project should be recorded in the team log or in the relevant GitHub issue so it is available to the whole team and doesn't get lost in only one partner's memory.
Tasks and commitments are tracked as GitHub issues, one per task, including non-code tasks such as drafting a memo or submitting estimates. Each issue has its owner as the assignee and a size: label for its estimate (and joint if applicable), and planned tasks should belong to a milestone with a target date. Close an issue when the task is done.
Deliverables and records — the team kickoff, team log, plans, memos, reviews, and change impact analyses — are plain text files in the docs/ directory of the appropriate repository. These are the official versions that are assessed.
Google Docs (or similar) may be used as a scratch space for writing together in real time, such as taking notes during a meeting or drafting a memo. Final versions must be copied into docs/; anything that exists only in a Google Doc doesn't count.
If you're going to miss a target date, tell your partner before it passes, not after, and update the issue.
Most development in a team project happens independently and the goal in dividing up tasks between partners is a fair split.
Steps in the planning process:
Define the tasks. Create a milestone for the plan and an issue for each task in it, with a title and a description of what the task involves. Leave the assignee and size label blank for now. (Tasks may be specified for you in the handout, or you may need to identify them yourselves.)
Estimate effort for each task (see Effort Estimation). Assign size: S, size: M, size: L labels to issues reflecting the agreed-on estimates. Address any differences between each partner's independent estimates and how you resolved each one in the plan summary in docs/ (have a separate file for each plan).
Assign owners. Decide who owns each task (see Ownership), then set each issue's assignee accordingly. To balance the work, count S = 1, M = 2, L = 4 points. Each partner's share should fall between 40% and 60% of the total for each of Part A and Part B. (Doing less on one part can't be made up by doing more on the other.) Within a plan, each partner must own at least one task and joint tasks may make up no more than one-third of the points. Note each partner's point total (count joint tasks as half to each) in the plan summary in docs/.
Agree on interfaces. Where one task depends on another, agree on the connection point (method names, parameters, behavior) before either of you starts and record it in both issues.
Reflection. Once the work is done and all of the issues are closed, add a brief reflection (a few sentences to a paragraph) comparing the S/M/L estimates to the recorded actual sizes — where were you off and did the differences discussion predict it?
When estimating a task's size, include the time to write its tests. As an approximate guide:
A task bigger than large must be split into smaller tasks. If you are unsure how to decide between two sizes, choose the larger — uncertainty about details of the task is itself a cost since time spent figuring out what to do is part of the task.
When doing effort estimation for a set of issues:
Estimate independently. Without discussing estimates with your partner, give an S/M/L estimate for each task (by issue number), plus a one-line note on what you think the task involves. Submit your individual estimates on Canvas (PDF) before the team planning meeting.
Compare. In the planning meeting, discuss every task where your estimates differ: what was each of you picturing, and why? Resolve the difference. This may mean clarifying what the task involves, splitting it, or agreeing on a size. Update the issue description if your understanding of the task changed.
Record actual sizes. When you open a pull request, include the task's actual size in the pull request description along with a brief explanation if it differs from the estimate (e.g. "Actual: L — validation had many more cases than expected").
The comparison of independent estimates is a key step — the goal of effort estimation is a fair split of work, but just as important is identifying misunderstandings early — if two people give very different estimates for the same task, it is likely that they are picturing different things and that's something to reconcile sooner rather than later.
Owners. Every task has exactly one owner, who is responsible for completing it (with tests) and for opening its pull request. Work is assessed according to ownership (see Assessment).
Joint tasks. If you plan to pair program a task from start to finish, you may designate it as joint when assigning owners: give it the joint label, and its points count half to each partner. Both partners are responsible for a joint task and must be able to explain it.
Pair programming is allowed on team tasks. Pairing doesn't change ownership: the owner is still responsible for the task. When pairing, whoever is typing commits and credits their partner by ending the commit message with a blank line followed by Co-authored-by: and the partner's name and email as shown:
Co-authored-by: Arthur Dent <dent@xyz.edu>
Use the email associated with the partner's GitHub account so that GitHub credits things properly when showing ownership of commits.
Swarming means both partners working on one problem together. Use it for design decisions, agreeing on interfaces, and integration problems. Planning meetings are a form of swarming. Implementation is usually split — if you work together on implementation, use pair programming.
Follow the GitHub Flow workflow:
main always contains working code with all tests passing.
All code changes are done on a branch, one branch per task. Never commit code directly to main. (On the other hand, files in docs/, such as the team log, may be committed directly to main.)
Always ensure that your local main is up-to-date before creating a new branch.
Commit incrementally with meaningful messages, as in P0.
When a task is done, update your local main, merge main into your branch, resolve any conflicts, make sure all tests pass, and open a pull request. In part A, merge the pull request yourself once it's open; in part B, merge it after your partner has reviewed it. (This is a stricter version of the workflow from lab 4 — there you only merged main into your branch when GitHub flagged merge conflicts, but just because things merge smoothly doesn't mean nothing broke. Merging main first means you can run tests on the result and make sure everything works before updating the remote repository.)
When opening a pull request, be sure to include Closes #n in the pull request description so the corresponding issue will be closed automatically when the merge is complete.
Pull request reviews will be part of Part B. Coming soon!
Testing should be thought of from the beginning:
Before refactoring code that isn't covered by tests, write tests that cover what the code currently does. Run all of the tests before and after refactoring.
When adding new features, write a test plan outlining the scenarios before writing code. The tests themselves can be implemented before or after the associated functionality.
Your final code is only part of what is assessed. The list below is for reference — each item is created at a specific point as directed in each task's steps above and together they are a record of your process, not just the end result. Process is a big part of this project! Your commit history, handin tags, and Canvas submissions all provide timestamps to document process.
A0 (in your own repository):
A1 (individual, in your partner's repository unless noted):
A2 (individual, in your partner's repository):
A3 (team, in the chosen repository):
A4 (team, in the chosen repository):
Part B deliverables coming soon!
Most of the handin happens along the way, through the tags and Canvas submissions listed above. To finish:
When the whole project is complete, create a tag P1-handin on main in the chosen repository.
Make sure that I (sbridgeman) have collaborator access to both repositories. (This should have been set up in A0.)
Complete a peer evaluation. (Details to come.)
The course projects together account for 50% of your final grade in this course. There are two distinct components to the project grade:
Program and deliverable quality. (15%) Does the program correctly implement the specification and are the other deliverables complete and done properly (not just present)? This is assessed individually (on your own work for individual tasks and on your owned tasks for team code) and is graded against the stated program, code, and process requirements — a program missing functionality or crashing on bad input, documentation that's missing or incomplete, or process steps that weren't followed fall short here.
Skills standards. (35%) Your work also provides evidence towards the following skills standards. These are assessed directly from your deliverables, and some may be followed up on briefly in the handin meeting, where you may be asked to explain a specific choice you made. As with program and deliverable quality, evidence comes from your own work: your individual tasks and the team tasks you own.
Part A:
Change-impact analysis — before changing unfamiliar code, identify the classes and methods the change will affect. [A1 change impact analysis and reflection]
Branching and merging and pull requests — do each task on its own branch and merge it through a pull request, with incremental, meaningful commits. [commit history and pull requests for A1, A3, and A4]
Merge conflict resolution. [commit history]
Identifying real issues in code review — find actual correctness, standards, testing, and readability problems, not just cosmetic ones. [A2 code review]
Communicating review feedback — give feedback that is specific, actionable, and constructive. [A2 code review]
Project planning — break work into tasks, estimate them, and use the estimates to plan and divide the work. [independent effort estimates, issues and milestones, A3 and A4 plan summaries]
Applying a coding standard. [code]
Writing Javadoc — document each public class and method clearly enough that someone could use it without reading its code. [code]
Defensive programming — validate input and check for conditions that could make the program fail. [A1 seed input; A4 dice mode selection and script validation]
Exception handling — catch and handle exceptions where they can be dealt with meaningfully, including checked exceptions from file input. [A1 seed parsing; A4 script reading]
Refactoring code smells. [A3 pull requests]
Refactoring safely under a passing test suite — before refactoring, make sure the code's current behavior is covered by tests, and keep all tests passing throughout. [A3 pull requests and commit history]
Test planning — plan tests with reasonable coverage of normal, edge, and error cases, and justify what is skipped or deferred. [A1 and A4 test plans]
Writing JUnit tests and identifying and testing edge cases. [JUnit tests for A1, A3, and A4]
Part B standards will be added with Part B.
In addition, teamwork is part of the course engagement grade. Teamwork conduct is assessed through a structured peer evaluation at the end of the project. Your team log and pull request history are used to corroborate the peer evaluations.