We're heading into the home stretch. Here are delivery deadlines:

• Alpha release

  February 24. Partial functionality fully implemented, including documentation, installation on customer machines, testing schedule (including planned customer input). This is a lot more than "hello, world".

  Here are some rules/guidelines:

  • You may not submit (release) anything that does not come from your project CVS. (That should be obvious.)

  • The alpha release must be marked in CVS so that it can be recreated exactly as is at any later date, even after changes have been made on the way to beta.

  • Provide a document on your project web site that explains how to get the alpha release. (The degree to which that is possible will vary from project to project - anything from a self contained executable to download to instructions on contacting the team for an appointment to use the software in the lab.)

  • Arrange for at least one person on each team to exercise the alpha release from each of the other teams.

  • Write an appropriate release notes document, post it on the web site, and submit hard copy. You can point to on line material (requirements docs, testing schedule, beta plans, other useful stuff). No need for extensive hard copy.

  I will arrange to review each team's alpha release. I will try to do some of that during the Feb 26 Wednesday class.

  Testing

  One of the most important reasons for an early alpha release is that it makes it possible to start serious testing in time to use what you learn from those tests to improve the product. So at the alpha release you should have

  • A functioning bug database, already populated with the bugs you found since the alpha code freeze.

  • A test plan. Consider using Paul English's Usability Testing Contract

  • Code in your application that allows a user to report bugs easily while he or she is using your application. Perhaps that's by filling out a form you pop up, perhaps it's by prompting for email to a bugs address.(This is something you will not have time to do because I did not ask for it soon enough.)

• Beta release

  March 31. Bugs from alpha fixed. Nearly complete functionality. Nearly complete documentation. Testing schedule. Final decision limiting scope of final release.

• Sourceforge feedback

  April 23. Each team should provide an discussion of sourceforge use this year, for me to send on to sourceforge when I ask them to make our private project pages public. An update of the previous submission is acceptable.

• Release 1.0

  May 5. Publication (sourceforge or equivalent). Web page with executables, documentation, known bugs, wish list, feedback request, source code availability, ... All visible prose carefully proofread!

• Open house presentation

  May 14, 5-7:30. Demonstrate and discuss your project with the public - faculty, fellow students, passers-by. The Department will provide pizza.

  Teams will need to plan coverage. If you don't already have a poster (from the graduate student assembly this week) you will need one. There should always be at least two people at the demonstration at any time. Copies of documentation should be available for browsing.

• Maintenance release 1.1

  May 24. Fix bugs. Small tweaks. No new functionality. Last chance to polish the project before graduation.

• Performance review

  Some time between April 15 and May 15. 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.

Back to the course home page.