COS 333: Project Description 2

CS333 Project: Second Handout

Tue Mar 27 15:57:24 EST 2001

This page describes schedule requirements for the project in more detail. (The original project description is here and the planning slides shown in class are here.)

Schedule

   March 2001
             1  2  3
 4  5  6  7  8  9 10    meeting with bwk by 13th
11 12 13 14 15 16 17	initial proposal
18 19 20 21 22 23 24	spring break
25 26 27 28 29 30 31	draft plan, TA meetings  <= You are here.
   April 2001
 1  2  3  4  5  6  7
 8  9 10 11 12 13 14	prototype
15 16 17 18 19 20 21
22 23 24 25 26 27 28	alpha test
29 30
   May 2001
       1  2  3  4  5	beta test
 6  7  8  9 10 11 12	demo day
13 14 15 16 17 18 19	Dean's date

Further details will follow for later dates; there may be minor changes in requirements.

March 30: Detailed plan. By this date, each group must meet with their assigned TA to go over their project plans in more detail.

Description: You must be prepared to describe your project carefully; although I won't ask for another planning document, it's not a bad idea to write down a significantly more precise and complete version of what you have already done. It might include

List target language(s), implementation languages, other tools and resources you will use.
Provide an architecture that shows the components -- what the pieces are -- and how they fit together. Make it clear which pieces you will be creating and which you will be importing.
Give a specification of interfaces between components.
- e.g., if an interface is expressed in terms of objects, what are the methods, properties, and so on?
- if an interface is expressed in terms of information passed in files, what are the contents of the files?
- if an interface is a program, what are the arguments, inputs, and outputs?
In general, it is probably best to think in terms of objects, as the cleanest mechanism that includes all of these. No matter what, the intent is to specify the interfaces in sufficient detail that implementor and user need no other information. You will find it easier to design interfaces if you do some prototyping.

Schedule: You should list the tasks to be performed, who will be performing them, and target dates for when they will be done:

List a sequence of stages such that each represents a working system (McConnell's "staged delivery"). Each stage should be self-contained, should do something, and in principle could be turned in as the final result.
Give a list of milestones for each week in April, ending on Sunday evenings (April 8, 15, etc.). Each milestone should be 1 or 2 sentences listing what tasks you expect to have accomplished by that time. For example, "All items for all menus will be present but unimplemented ones will be disabled; all items on the File menu will be fully functional." You will not be held to these milestones, but thinking hard about them will help you to plan your time. Milestones must be binary, that is, things that are either done or not done; there are no "coding will be 50% complete" milestones.
Estimate the time you expect to spend and the amount of code that you expect to write. Looking back on these estimates can help you in future planning.

Miscellaneous:

Don't forget testing; you should always have something that has been tested up to the limits of what it is supposed to do; this will take time and planning.
Don't forget the other chores: written material, installation process, class presentation. Leave some time for these.
Don't forget risks: leave some slack for the inevitable delays and setbacks. People will get sick or swamped in some other class; tools will break or not do what you expect; systems will crash; your disk will self-destruct. Think about defending against such problems, and have some contingency plans.
Don't kill yourselves on this. Implausible as it might seem, part of the goal is for you to have some fun, and also to have a life. Planning ahead and delivering in stages are the best way to achieve this.

Your plan is not a binding commitment, since you will undoubtedly have to revise as you gain experience. But you will be graded according to how thorough and reasonable your planning appears to be, so try to do a good job.

In particular, you should freeze the list of features around this point; if you don't get them all done, that's fine, and if through some miracle you have time for more, that's fine too. But you should not be making major changes in what you have planned after this point.

April 13: Prototype. By this date, you should have a bare-bones prototype that shows approximately what you are trying to do, and what your system will look like. It need not do much, but it must do some minimal part of the job. You should not be considering major or even very many minor feature changes after this date. This should be one of the stages that you planned for.

You must meet with your TA by this date to demo the prototype, so he or she can assess your progress and report to me.

April 27: Alpha test. This should be another stage in your plan. By this date, you must demonstrate an "almost working" version of the core functionality of your project. "Core" means the basic operations that form the essence of your project; if you were doing Amazon-2, for instance, this might mean searching for books and accepting orders. "Almost working" means that wizards (you) can help experienced programmers (us) to use the system. Ideally, since this is a user-interface project, the use should be obvious, but some hand-holding is permitted. Your code may crash and need restarting. Since you have been testing carefully as you go, crashes should be quite infrequent. You must be able to convince us that your project can be completed by the deadline.

You must meet with your TA by this date for another demo, so he or she can assess your progress and report to me.

May 4: Beta test. Your code should largely work, all intended features should be installed and working, no major component should be incomplete. A determined sadist might be able to break your system, but a casual experimenter should not. (Your TA will be somewhere between these extremes.) Drafts of written material and web page should be done.

May 10: Demo day. Each group will give a brief (20-25 minute) quasi-public presentation of their work; other groups are strongly encouraged to attend, for instruction and moral support. You will also be required to attend at least a few other presentations, for instruction and moral support. A one-page marketing blurb and a web page must be available for interested users. I would also like to encourage real use by naive users: your classmates on other teams. You must attempt to use some of the systems written by others and see how well they work.

May 15: Dean's date. Everything must be done and handed in by 5PM on this date, without exception. Final submission has to include your code, installation procedure, a man page, a web page that would induce others to use your system, an internals document describing the implementation, and a report on how the project and the team worked out and what was learned. (These will be specified in more detail later.)