Course projects in my versions of 431 are run along the lines originally laid out by Elaine Kant at CMU in the early 80's. (See ACM Software Engieering Notes, 1981). Basically, these involve teams of 4-5 people, but I tend to require everyone to work on the same problem in order to both make grading fairer, and allow me to take parts of lectures to discuss problems I encountered with the project documents as they are being submitted, which should then be of interest to everyone. ( Here is a link to an older version of the document that was handed out in lecture, which describes the general aspects of the project.)

The project this term: The project this term will deal with Karel, a small programming language that is intended for teaching students of all ages.

• The original language and its principles is most fully described in the book "Karel the Robot: A gentle introduction to the Art of Programming " by Richard Pattis, which is available on reserve in the SERC Reading room.
• This is a sample short on-line summary of what Karel is supposed to be capable of.
• More generally, here are implementations associated with a number of variants of Karel available at sourceforge.net
• Finally, here are some thoughts on what I would like to have.
• Any other information can be obtained by "interviewing" me, the potential customer. (I have already provided far more information above than I usually do in this class.)

Project deliverables (and what we look for while grading):
The following is a list of deliverables, described in the handout which you have, together with due dates. It is your responsibility to read the handout and to prepare these documents on time. We expect one paper copy to be handed in, and an electronic copy to be submitted via handin by the beginning of the second lecture of the appropriate week of the course. (The first week starts Monday, January 16; Spring break does not count as a course week.)

• Storyboards and Prototype Implementation (Week 3 (Feb 2) - demo to be scheduled)
• User Interface
• Functionality
• Examples worked out for all normal case uses. (no error checking,...)
• Some Java code giving you an understanding of how to implement the so-called Model-Observer pattern using the SWING library (probably the most questionable new technology you will be encountering).
• Requirements Document (Week 4) (Feb 9) (In addition to your handout, here is a document describing the IEEE organization's suggested standard for software requirements specifications (SRS)
• Use-cases and scenarios (supported by specific examples) rather than verbose descriptions
• Abnormal/error conditions as well as normal case handling.
• Precise descriptions whenever possible (Use grammars, automata, regular expressions.)
• Thoughtful subsetting into "kernel, reasonable, advanced,..." categories. (Everyone finds themselves running out of time at the end of the term!)
• Non-functional requirments.
• Architectural Design Document (Week 6)(Feb 26)
• Good modularization, which supports information hiding/abstraction/implementation secrets, allowing easier modifications later on.
• Modularization that helps the "subsetting" suggested in the requirements.

Systematic specification of each module (including imports, exports, error signals, assumptions of methods).
If you are interested, Tanvir has researched custom tags in javadoc, and this tar file contains i) some java files needed to use tags like @requires, @effect, @modifies (the others like @param, @returns, @throws are built in); ii) an example of a search program annotated as I discussed in class; iii) a short html file explaining custom tags.
• Appropriate use of iterators.
• Design Walkthrough (to be scheduled during weekend) (Feb 25/26)
• Detailed Design Document (week 9)

(March 26)
• Fixing problems revealed in walkthrough. (It is perfectly reasonable to change the architecture of the software, to improve it.)
• Code reuse through libraries.
• Coding (Weeks 10-14)
• Clean, well-documented code
• Test Plan Document (Week 11)(April 11)
• Each student must provide good black-box and clear-box test data for at least one interesting class  which is going to be tested by him/her.
• Precise integration plan with dates.
• System Delivery/Freeze (last day of classes)
• System Demonstration (to be scheduled during reading days)
• Make sure you practice a 'script' that shows off everything you have done, without bugs showing up.
• Afterwards we will 'take control' to try to wreck things.