Homework 5: Plan

Now that you've translated your design into requirements, and your requirements into an architecture, it's time to plan how you're going to work together to build your application.

PM's, lead the authoring of a GitHub page that answers the following questions:

1. How will you coordinate your work?
   • Who will coordinate the work?
   • What will their project management practices be?
   • Will you have meetings? How frequently? Who plans their agendas?
2. What tools will you use to communicate?
   • For each, articulate the alternatives and why that is the best choice.
3. Who will own component in your architecture?
   • Owning them means being responsible for writing them and making sure they are functional and correct.
   • For each component, list the one person who is in charge of getting it done.
4. What is your timeline?
   • Include a list of milestones you'll reach and deadlines for each.
5. How will you verify that you've met your requirements?
   • For each requirement in your requirements document, detail how you will verify it, and if you won't verify it, justify why you won't. This is called an acceptance testing plan Links to an external site..
     • If you propose to write a tests, what exact tests will you conduct and what will count as each test passing?
     • If you propose to conduct reviews or inspections, how will you analyze the code?
     • If you write a proof, what property will you prove?
     • If you conduct a review or inspection, what aspects of the code will you inspect to verify the requirement is met?
   • For all of the requirements, how will your verifications be integrated into your process? Will you run automated tests after every build? Before every commit? When will you conduct inspections and who will be involved?

For each answer you provide, provide a written justification that explains the rationale behind your decisions, given what you know about what you need to build. I want to incentivize you to think deeply about each of these choices, to make sure your process decision actually makes sense.

To make a good plan, brainstorm disasters that might happen and test your plan against them. Illness, injury, API limitations, difficult to fix bugs: how resilient is your plan to all of these crises?

Approach

Developers lead

Items 1-4 above should be relatively straightforward. Devising a clear verification plan, however, is more difficult. To do this, follow the systematic Create an Acceptance Testing Plan Links to an external site. strategy on HowToo. Leave a comment on your experience using the strategy for 1 point of this assignment's credit. Remember that the comment must not be anonymous.

In class

In Discord > Team Channels

PM's lead

Try to finish items 1-4 in the list above in class today. In instructor/TA meetings,  discuss each of these with us, and convince us that you have a clear plan. If you have time, begin item 5, your verification plan.

Grading Criteria

Submit a GitHub link to your plan to Canvas for credit. Rather than copying your requirements, you can simply update your requirements document with verification details. 

A good process is consistent with reality. You'll get 4 points if you 1) answer all of the questions above and 2) the answers you provide are account for the reality of your schedules, availability, and time. For every part of your process that seems either unnecessary, vague, or infeasible, you will lose 0.2 points. To make sure that your proposed process doesn't have these elements, be explicit not just about who is doing what, but what exactly they are doing and why they are the right choice and why they have sufficient time, expertise, and resources to do it. Being explicit will help us assess how rational your decisions are, but more importantly, it will help you be more rational about your decisions.

For the last remaining point, one of your teammates should post a detailed non-anonymous comment on the HowToo strategy, discussing the pros and cons of how it did and did not support your work.