Author: Ric Holt, Department of Computer Science, University of Waterloo
Modified by: Grant Weddell, Department of Computer Science, University of Waterloo
Modified by: Ian Davis, Department of Computer Science, University of Waterloo

(installation manual and project report due in class on Nov 30th, 1999)

BACKGROUND

This assignment is a follow-on from Assignment 1, in which the goal was to design a Software Architecture for either the OAM or CU components of the SX4 telephone switching system, and Assignment 2, in which the goal was to produce a corresponding Detailed Design.

The following constraints are imposed by the management:

• (1) Implementation is to be done in C or C++.
• (2) All documentation (including the solution to each assignment) is to be web-readable, eg, in HTML (or other form readable from the web). At the same time, documents must be printable (you are to turn in a hard copy for marking).
• (3) You are to work in the same teams as for the second assignment.

GOAL

Each project team must now do an implementation and functional testing of their detailed design of either the OAM or CU component of the SX4 switching system. There are three parts relating to the "deliverables" for this assignment. The first two parts are documents that must be submitted in class on the assignment due date. The third part is a demonstration of your implemented system for the management. The exact scheduling for each group's demonstration will be negotiated.

The first document is an installation manual consisting of no more than one or two pages. The manual should provide all necessary information to other project teams on how to compile, link, install and run your software.

The second document is a project legacy report. The report should be useful for a number of purposes: help in reading the source programs, help in maintaining the programs to fix problems or add new features, help in clarifying the relations between the Detailed Design and the implementation, etc. The readers will include programmers and managers.

Your report should include the following:

Title: About 3 to 6 words making clear what your report is about.

Authors: List of authors, their addresses, date, etc.

Abstract: About 2/3 of a page that is an overview of the key points in your report, targeted to a programmer, developer or manager.

Introduction and Overview: About 1 to 3 pages summarizing the purpose of report, its organization, and its salient conclusions. A person should be able to read just the abstract or just the introduction and have a good idea of what is in the rest of your report.

Revisions of Detailed Design: How did the implementation vary from the detailed design, and how was the detailed design updated? Explain any changes in architecture as well.

Status of Project:

• What was accomplished.
• What problems where encountered.
• Anything not done.
• Anything requiring future attention.
• Any areas where future enhancements expected.
• Give a concrete example of at least one expected future change or enhancement of your system. Explain how difficult, including simple impact analysis, you expect future changes to be.

Test Coverage: Provide the following information for each integration task.

• The selection of individual test runs, together with the results obtained for each run.
• The percentage of source lines for the modules that comprise the test thread that were exercised by the test runs, together with a brief summary of what parts of modules and functionality were not exercised.
• Explain how the tests would be used to test future versions of your system.

Also, in an appendix, list any additional source code used as test harnesses.

Task/time log: Referring to your cost/duration estimates provided in your earlier detailed design, give a table showing estimated and actual times. Note that this implies that each team member must keep a careful log of time spent on individual build and integration tasks. Briefly explain any significant differences between estimated and actual time.

Directory Structure: Your code and associated documentation should be stored in a directory structure that is very easy to browse. Each directory must contain a README file that clearly informs a programmer or manager the contents and purpose of the directory. Describe the organization of your directory structure.

Recommendations for Future Projects: Give constructive suggestions for how this project might be done differently in future versions of this course, to improve the learning experience.

Do not make your report longer than necessary. In general, shorter reports that contain appropriate information are preferred. Your report should not be longer than 10 pages (in the hard copy version); this limit does not include the source code for any test harness, which should be in an appendix to the report.

Write clearly. Organize your report so it is easy to find things in it.