Here are the formal, dated deliverables. Of course there are intermediate ones you will schedule individually, internally for the team and externally with your customer. And of course everything you do must be transparent - visible on the project web page and subject to surprise inspection.

• From first team meeting ...

• October 14: Vision statement and project web page.

• October 30: Looking for venture capital: project presentation.

• December 4: Requirements analysis (and more).
  • Use cases (customer approved as appropriate, prioritized)
  • Hardware and software requirements
  • Risk analysis (update)
  • Schedule (update)
  • Development methodology
  • Critique/analysis of work to date
  (more information to follow).

• February 1: First formal application checkpoint. Working program (if only "hello world"). (Of course your project schedule may call for this milestone sooner - particularly if your team plans a long winter break.)

• March 11: (just before Spring break) Alpha release. Customer can install, use, test software (limited functionality). Alpha documentation included in release. Test plan.

• April 20: Beta release. (Almost) full functionality, ready for test. Cautious schedule for new features after this, since you don't want to break what's working.

• April 27 and 29. Presentations to class and guests. Last chance to practice your speaking and listening (and powerpoint) skills. Each team will have half an hour (plus 10 minutes for questions) on one of the two days. The choice of content is yours - you can discuss project process, history, architecture, future, ... . Just a demonstration of your application is not enough (though you may include one). The guiding principle should be to prepare a presentation that you would like to listen to at the end of your year studying (and practising) software engineering. It should be lively, informative and compelling. Extra points for questions from the audience, points off for putting people to sleep. I expect to invite faculty and the graduate students who will be taking this course next year. I will advise you on the planning and execution in the time leading up to the presentation.

• Performance review

  Since we began the year with a simulated job interview we should finish with a simulated performance review, so I can decide by what percent to increase your salary. I will provide a signup sheet for these meetings. You should provide
  • An updated CV and web page (since you will be moving on ...)
  • A sample of your work on your project (code, perhaps documentation too). (This is in lieu of the code reviews we never got around too. And it's something you may be asked for at a job interview.)
  • A fair discussion of your sense of how your strengths and weaknesses affected your team's performance.

• May 6: Optional presentation at CS Alumni event.

• May 11: Production release (1.0). The principle that governs the details of what you must do: leave the project in a state that the customer is pleased with, and that you would be pleased to maintain.

  • Complete tested application, installed/installable by customer (as appropriate).
  • Complete documentation (for users, installers, programmers) on web page. Proofread, of course.
  • Web page (probably at sourceforge) up to date, including sourceforge release and prominent pointer to list of known bugs (of course a production release should have no bugs - but this is real life ...)
  • Release flagged correctly in CVS tree.
  • Hard copy:
    • Acceptance from customer.
    • Appropriate documentation.
    • Bug list.
    • Your poster (framed, small format) for me to keep in my office to impress future SE classes.

• May 12: Presentation to public - poster and demo - at annual department Spring party.

• May 20: Maintenance release (1.1).

• June 4: Graduation.