We are going to work on this phase in class on Monday and Friday, so please get started before then so you can use the time during class most effectively.
Write a document that describes three things: your overall System Architecture, a set of Deliverables, and a Development Schedule for those deliverables. This document should look more like an outline or a piece of documentation rather than an essay: structure it with lists, sections, diagrams, and code snippets, rather than paragraphs. Submit it as a PDF. 4 pages is probably too short; 15 pages is probably too long.
The three sections of your document will all depend on each other. This means that you can't write it in one go, in order. Read this entire page, work to sketch out your system architecture, add detail by describing the deliverables, and think about the development schedule. In the process, you'll figure out more about the architecture, for example, and realize changes you need to make to the deliverables. Do many passes until you converge on a consistent document.
Remember, as with so many things in this class, there is no single right answer, and you may feel a little lost. The point is to do your best and think carefully; this phase is designed for your benefit, not for me to grade you based on some super-detailed checklist. Ask questions when you've got 'em.
Create a diagram showing the grouping and interactions of all the different components of your application. Use Balsamiq to draw your diagram. It should look like a more detailed version of the figures I've drawn on the board regarding the interactions among the client, the server, and the database. Every software component in the Deliverables section should be represented in your diagram.
Here's one way you might wish to group the components of your application: client side and server side, with server side subdivided into controller (logical components that process information coming from the client), model, database interface, and view (components that build the representation to be sent back to the client).
A deliverable is a thing, not a process for creating a thing. The second part of your document should describe the things that will make up your project.
Describe all the different components of your webapp, including software components (functions, classes, methods, data members, etc., in Python and also Javascript if you're planning some client-side logic), auxiliary data (HTML templates and snippets, CSS files, metadata like database hierarchies, etc.), and your database. Try to divide them up into higher-level groups (front-end, back-end, model, view, controller, core logic, abstraction layers, etc.). For each function, first write its signature as an actual little code snippet (def foo(bar, baz, wakka)), followed by a description of its arguments, outputs, side effects, possible exceptions, prerequisites, guarantees, etc. This document should describe external interfaces and behavior, not implementation.
Each distinct deliverable should be paired with a corresponding test deliverable. Show me how you'll organize your tests, and how you'll verify that each component you build is correct and complete. You may want to use the Python standard library's unittest module — here's a good tutorial.
Try hard to make your descriptions complete and consistent with each other. You may not be able to do a perfect job at that, and that's okay. Try to highlight each uncertain area, accompanied by a short explanatory note, so that you'll know explicitly later what you'll need to decide about, and how.
Write a schedule of discrete dates when certain tests will pass, or when certain properties of deliverables will be true. Note that this is different than saying when you will work on things. Write them as a sequence of present-tense, declarative statements in bullet points. For example:
Candidate class.DataSource.getCandidateList() returns a correct candidate list from the database.Don't forget to include deadlines for all of your components!
Here are some deadlines for the upcoming phases, and what they'll involve:
(The eagle-eyed among you may notice a discrepancy between this and the original plan that I presented to you in class, which had eight phases. The former phases 4 and 5 have been combined into this single assignment, now just called Phase 4.)
Check in your PDF (and source file[s]) and tag the commit with phase_2_4. Remember that the push for your commit needs to be separate from the push for your tag!