CISC 475 Object Oriented Software Engineering, Fall y2k

Writeup submission guidelines for construction phase 1

Include a printout of your Elaboration documentation exactly as submitted previously. It is acceptable to turn in the graded copy or a fresh identical copy.
Include 2 copies of your current report, with the following elements:
1. Overview:
  Inception/elaboration document features (sponsor, goals, etc) as modified (possibly twice now). Document should contain last modification date.
2. Use cases:
  These also should contain creation date and modification dates. Thus the reader should be able to see at a glance if a use case (a) hasn't been modified, (b) has been modified in this phase, or (c) is new this phase.
3. UML Diagrams:
  These should be refined as to number of classes specified, and showing greater detail where appropriate. For instance, show full listing of the class members in a class diagram.
4. Status report
  Summary of results achieved and how they compare to expectations three weeks ago.
5. Phase 2 plans.
  State concrete achievement goals for phase 2 as well as division of responsibility among team members. It is expected that phase 2 results will be a beta testable version of the system. This means that all the major components are present and work with each other. However many intended functions and details may be unimplemented. This should be a version that an outsider to the team can try out and give useful feedback regarding bugs, regarding overall effect, etc.
6. Coding standards
  Include a description of the standards you have adopted for your code and comment style conventions. This does not have to be elaborate. It can include naming conventions, indentation and bracket placement conventions, comment placement and form conventions. Naming conventions might include what kinds of names get what kinds of capitalizations, where initial underscores are used, etc. For instance some people have all private field names begin with an "_". Comment conventions might include how pre- and post-conditions are formatted. You could just say you will use the javadoc tags @param and @result, for instance.
  It is expected that all your code adheres to your standards. Clarity and consistency throughout the project are the goals.
7. Detailed specifications and code.
  Specifications must include (but not be limited solely to) statement of class invariants and pre- and post-conditions for each public member function. Hand in no more than 10 pages of code containing full specification. Select and offer some key, fully specified code if you have more. Minimal requirement is one fully specified class. Include some test code (does not have to be as fully documented as project code). We recommend "enscript -2r" for generating code printouts. More fully, "enscript -2r -psmips MyClass.java", for instance. Nice touch to include the javadoc (or similar tool) printout of the specifications.
Staple or clip each of the three parts (old, new, new) separately. Grading remark: This material will be evaluated for progress this phase. To emphasize: if old = new, grade this phase is F. Fortunately old=new is not the case! Refinements of requirements, introduction of detailed specifications, measurable code production, and clearly stated, concrete, pragmatic planning statement all count to the good.