COS 333: Project Description 1

CS333 Project: Second Handout

Sat Mar 18 10:21:33 EST 2000

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.)

Some issues surfaced in several projects; read these notes for general comments that might apply to your proposal.

Schedule

    March 2000               April 2000               May 2000
 S  M Tu  W Th  F  S     S  M Tu  W Th  F  S     S  M Tu  W Th  F  S        
          1  2  3  4                       1        1  2  3  4  5  6
 5  6  7  8  9 10 11     2  3  4  5  6  7  8     7  8  9 10 11 12 13
12 13 14 15 16 17 18     9 10 11 12 13 14 15    14 15 16 17 18 19 20
19 20 21 22 23 24 25    16 17 18 19 20 21 22    21 22 23 24 25 26 27
26 27 28 29 30 31       23 24 25 26 27 28 29    28 29 30 31
                        30

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

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

Description: You should prepare a written document of several pages that describes your project carefully; this is in effect a significantly more precise and complete version of what you have already done. It will 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 2, 9, 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.
Provide estimates of the time you expect to spend and the amount of code that you expect to write. Subsequent reports will ask how good your estimates are, so try to estimate accurately and keep decent records.

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.

Send a draft of your plan to your TA 24 hours before your meeting. After discussion with the TA, revise the plan as necessary, and submit it to the TA and to me by midnight on Sunday, March 26. Your plan is not a binding commitment, since you will undoubtedly have to revise as you gain experience. But it 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 at 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 7: First 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. Since this is in large part a user interface project, the interface itself should give a clear idea of what you hope to provide. 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 21: Second prototype. 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 ability to create, edit, compile, see messages, edit, and run, as appropriate for your particular interface; you should discuss with your TA what a reasonable set of functions would be. "Almost working" means that wizards (you) can help experienced programmers (us) to use the system. Since this is a user-interface project, the use should be obvious, but some hand-holding is permitted. Since you have been testing carefully as you go, crashes should be quite infrequent.

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

April 28: 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 3-5: Demo days. 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. 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. Depending on how projects shape up, this may be done by area of interest.

May 9: 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.)