Back to Homepage

Homework 7 - Release

In just over three 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.

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.

Grading Criteria

Submit a URL to your final deployed application on Canvas and we will post it on the course website.

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

• How many of your planned requirements you met. "Planned" requirements are those that were present in your requirements document from Homework 3. We will capture a snapshot of your requirements document two weeks before the release deadline and base grading on those requirements. Update your requirements accordingly to make sure that the requirements you included are still the ones you want to target.
• How well you correctly implemented your planned requirements.

To evaluate how many of your planned requirements you met, you'll annotate all of the requirements in your Homework 3 requirements document as either complete or incomplete. We'll count the proportion of your planned requirements that are complete and multiply it by 10, rounding to the nearest integer. We will verify each requirement tagged complete by using your application.

Then, in Homework 8, 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, rating its severity on the following scale:

• Major. Functionality cannot be used to accomplish the intended task.
• 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 1 point. 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!

You'll need to make sure your repository is accessible to anyone so they can submit issues. You'll also need to create GitHub issue labels that match the scale above so your classmates can submit issues with those labels.

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.