CSE 436 Software Engineering Workshop
Instructions for Team Projects Final Report
Due by 10am Monday April 30, 2007

Each team should please submit a final report for their semester project (in .doc, .txt, .ps, or .pdf format) to Professor Gill via e-mail at cdgill@cse.wustl.edu by 10am Monday April 30, 2007 (late submissions not accepted except in extreme cases).

In compiling this report, you may incorporate material from the most up-to-date versions of your previous documents submitted in the course, but please make sure to check the entire document for consistency, including formatting, terminology, and cross-references.
Specifically, the document should be self-contained and should refer only to sections within itself, and not to other documents – if necessary please create additional sections of your final report, beyond the following required ones:

1. a title page, with the project’s name, the nature of the document (final report), the date of submission, and the names of all the team members who contributed significantly to the report (all team members are expected to do so).

2. a table of contents that lists the major sections and subsections of your report;

3. a glossary containing all the technical terms used in the report, which should list each term and give a concise but rigorous definition of its meaning;

4. an overview section with a description of 

a. what the core idea of your team’s project is,
b. what problem that core idea addresses,
c. how the core idea addresses that problem,
d. an overview of how your team’s project fits with the other teams’ projects, including describing how any features of your project may depend on features of another project and vice versa (and noting for all such cases which of the features are essential and which if any are peripheral);

5. a listing of the requirements from your RDD, with a numbered label on each requirement (e.g., 1, 2, 3), with a breakout of each requirement into in-depth sub-requirements, each with a numbered label that contains the label of the top level requirement from which it came (e.g., 1.1, 1.2, 1.3, and then 2.1, etc);

6. an architectural diagram showing 
a. the major subsystems and components of your project, 
b. the external interfaces with your system’s environment,
c. external interfaces with other teams systems, 
d. major connections among the components and external interfaces,
e. optionally, internal interfaces among subsystems of your project, and
f. optionally, some of the main objects in your design;

7. a detailed mapping of the requirements breakout onto the subsystems of your project and of the systems of other teams projects;

8. a list of the components in your architecture specification, giving the following description of each component:
a. the component’s name,
b. a brief description (a sentence or two) of the component’s responsibilities,
c. the names of all other components on which it depends,
d. the names of all other components that depend on it, 
e. each object within the component, and
f. the numbers of the requirements from your revised SRS document which are mapped to each object in the component – if you list more than one object for a requirement or more than one requirement for an object, please add a brief statement explaining why that multiplicity is appropriate;

9. a short narrative (a separate section) identifying and justifying each of your decisions in breaking out the different components in your architecture specification as you did and why you believe the responsibilities of each component in your architecture specification are similar enough that no further subdivision is needed.

10. a section that names and shows the external interfaces of your system;

11. a section that provides detailed interface specifications for each of the objects – to save duplication of effort at the implementation stage, you may write your interfaces directly in Java and then for this section turn in either the interface code or javadoc generated from the interface code; and

12. a section that summarizes the progress of your implementation, identifies and discusses any risks, problems, concerns, etc. that either have slowed your progress or that remain as open issues with your implementation.

Please also submit a separate zip file (or gzipped tar file, etc) containing the interfaces and source code for your implementation, and containing a separate text file with instructions for how (and on what platforms) to build, run, and demonstrate the code.

As before, please check your document for grammatical and spelling errors before you submit it (treat it as though you were submitting it as part of a professional product).
We will grade the final reports according to the following rubric:

25% document’s clarity, readability, and understandability by a general audience
25% the completeness and quality of the requirements
25% the design-level architecture and how well the requirements map to it
25% the quality and scope of the implementation

We will assign each document a numeric score out of 200 possible points, and will give feedback to the teams by Monday, May 7, 2007.