Homework 6: Release

In about four weeks, you're going to launch your 1.0 product. Excited? Daunted? I hope both! If you've done a good job preparing for your implementation phase, there are several things that should make your process smooth and uneventful:

• You should know what components you need to build and who is building them.
• You should know how you're going to verify that your product meets its requirements.
• You should know how you're going to coordinate and communicate over the next few weeks.
• You should know what technologies, APIs, platforms, and languages you're going to use.
• You should know how to build your project.
• You should know how you're going to test your project.

If each of you is putting a solid 10 hours per week of implementation time, plus 5 hours of in-class coordination and planning time, you should have plenty of time to reach this deadline.

In class

In Discord > Team Channels

PMs Lead

First, lead the team in a discussion of the grading criteria. What implications does it have for your work that you haven't already accounted for?

Next, review your plan to make sure everyone agrees on it:

• Who owns what?
• What are your milestones?
• How will you communicate and coordinate your work?
• How will you use class time over the next three weeks? You'll see that each class period is open-ended work time on Discord, with continued checkins with the instructor and TA.

You should have answers to all of these in the documentation you wrote for your previous homeworks. Review them and make sure everyone has the same understanding of their responsibilities.

In your time with the TA or instructor, ask any clarification questions about the work or grading criteria.

Approach

On all previous assignments, you were encouraged to use strategies on HowToo to structure work. We strongly encourage using HowToo strategies during your development! Search, browse, and try strategies when you get stuck, and request strategies if you can't find a relevant one.

To incentivize sharing your knowledge, each individual that writes a strategy in response to a request can earn their team up to 1 point of extra credit per strategy (up to a maximum of 3 points). To earn the point, someone must use your strategy, and write a non-anonymous comment summarizing their experience, and explaining how it helped them. To encourage this, I suggest sharing links to strategies on Discord, and pointing classmates to your strategies when they ask for help.

Grading criteria

You'll submit two things for credit:

1. You must also post the URL to the live site using the release Links to an external site. feature on GitHub.
2. You must submit a URL to your annotated requirements document to Canvas, as described below.

A successful launch gets 15 points. To determine a "successful" launch, we'll consider two factors:

• The proportion of requirements you met.
• How well you correctly implemented your planned requirements.

To evaluate how many of your planned requirements you met, on GitHub you'll annotate all of the requirements in your requirements document on GitHub as either complete or incomplete. If there are requirements you cannot meet because they turned out to be impossible for reasons out of your control, you can mark it as impossible and explain why. Your job is to persuade us there was no way to meet it. If you persuade us, you will not be marked down for impossible requirements. If there are requirements you revised from when you first submitted them, you mark them as revised and explain why you had to revise them. Your job is to persuade us that it needed to be revised. These will be treated as complete, and be included in the total number of requirements. If you persuade us, you will not be marked down for revised requirements that are complete.

Your requirements should already be numbered; put the appropriate tag above immediately after the number, so we can easily count and classify your progress. We'll count the proportion of your planned requirements that are complete and multiply it by 15, rounding to the nearest integer. We will verify each requirement tagged complete by attempting to use your application. If we can't verify it, then we will not count it as complete.

In Homework 7, all of your classmates are going to try your software on the tasks it is intended for. For every bug they find, they'll submit an issue to your repository, labeling the report with one of the following GitHub issues labels:

• major. Functionality cannot be used to accomplish the intended task.
  • Usability issues, including interaction design, visual design, and content that prevented someone from understanding how to use the application do count as major. It doesn't matter what your intended design was; it's your job to make it usable.
  • You can disagree that something is major by posting a comment in the issue, arguing for why it should be minor. The instructors will read your arguments when making their decision.
• minor. Functionality can be used to accomplish the intended task, but requires a workaround to be used successfully.

For every major issue, you'll lose 0.5 points. This does not include duplicates, but it's your job to mark duplicates, so that we don't count them. Create a duplicate label so we don't count them against you.

You won't lose points for minor issues; all 1.0 products have these problems. Note that if you have a large number of major issues, it's possible to submit a mostly working application that receives zero points. That means that comprehensive verification is paramount!

To enable your classmates to submit issues and indicate their severity, use GitHub's issue template feature Links to an external site.. One template should have a title prefixed with [minor], and another template should have a title prefixed with [major]. When a visitor submits, they should choose between these two templates when submitting, so you and the instructors can distinguish between minor and major issues. If you do not create these templates, you will lose 5 points.

Remember that GitHub tracks history on everything, including changes to wiki pages and changes to issues. We'll be using that history to determine grades. Feel free to make whatever changes you like to issues and your wiki. We'll inspect the history of these changes to determine grades.

Finally, a note on failed launches: if we can't verify your completed requirements or your teammates can't launch your application, that is considered a major defect, and your classmates are justified in reporting it. This does give you some slack in launching, but puts you at risk of a classmate reporting a major defect.