Doing a Masters Project Under Nan's Direction

Disclaimer

Contents

My Interests

Expectations

Deliverables

Writeup Contents

Defense

Users' Guide

Technical Documentation

INTERESTS: My current interests are projects related to computer graphics and/or parallel computing. In particular, my focus right now is on java and VRML projects that can be linked to my courses page and help to teach concepts in either area. For examples, see

http://www.cs.rit.edu/~ncs/graphics.html#educationAp

and

http://www.cs.rit.edu/~icss571/Projects962.html

Another area I am interested in is using java to teach parallel computing; see some starting points at http://www.cs.rit.edu/~ncs/parallel.html#languages

I have also linked some other on-line project things to my courses page:

http://www.cs.rit.edu/~ncs/Courses.html#masters

I am willing, however, to consider other projects.

EXPECTATIONS: While I am interested in projects in the areas mentioned above, I do not consider it my responsibility to come up with projects for you. That is your responsibility.

It is also YOUR responsibility to create your project writeup (see below) using proper English, proper spelling and good organizational structure. I should not have to do major editing on this document - be aware that YOU WILL NOT FINISH until this writeup is in (at least) reasonable shape. You may hire someone to edit your document.

As the department requires you to create a web page for your project with your documentation, etc. online. I expect you to add a table to this page that details the components that you need to do to complete your program, your anticipated finish date for each part as well as the date you ACTUALLY complete each part. For example,

This will serve three purposes. You can see how you are progressing; I can see how you are progressing and it may also aid other students in generating a realistic timeline.

If you don't know how to create a table in html, you can always View... Page Source for this page.

DELIVERABLES: I have a minimal expectation for deliverables for a master's project. These include:

The system (You must clearly demonstrate that it works! AND, I must be allowed to try to break it!)

A project writeup including a User's Guide and Technical Documentation for the project as appendices. If the projects are java/VRML based then the documentation should ALSO be available online. ONLINE documentation is NOT sufficient.

Possible guidelines for both the User's Guide and Technical Documentation are attached. The User's Guide should allow someone who has never used your program to do so after reading it. The Technical Documentation should provide enough of and the kind of information to enable someone who is trying to maintain or extend your system to do so. It is a very good idea to include screen dumps of key images where appropriate.

WRITEUP CONTENTS: A possible outline of your writeup might contain:

Title Page

Abstract

Table of Contents (include page numbers)

Introduction

Background (why you are doing it - results of any literature research.)

Implementation (describe what you did and the problems encountered in getting there!)

Results

Limitations

Future Work

Conclusions

Appendices (include User and Technical Documentation here)

Bibliography

NOTE: You will need to hand in THREE bound copies of your writeup - one for your advisor, one for the reading member and one for the department.

Scheduling Your Defense: You think you have finished your project. What's next?

1. At least one month before your defense date, schedule a demonstation with your advisor and see if he/she agrees.
2. At least ten days before your defense date, a finished, "bound" copy of your final report should be in the hands of your committee. See Section 6 of the Master of Science Program Student Handbook for details regarding departmental requirements in this area.
3. If both of the above are acceptable, find an acceptable date and time for your defense. Acceptable means that minimally your advisor and reading member (and, of course, you) must be able to make it (1 - 1 1/2 hour time period). An observer must be there as well, but if you've already found one who cannot be there, a replacement can usually be found. (One way to do this is to send the info about date and time to the Computer Science faculty and ask for a volunteer.)
4. Contact the Computer Science office staff and ask them to arrange a room for you. It is up to YOU to make sure that the room is equiped with whatever it is you need. See Section 6.6 of the Master of Science Program Student Handbook, for a checklist for the defense.
5. Construct an e-mail announcement to be distributed to the Computer Science Faculty at least TEN days in advance of your defense.
6. Create a printed announcement to be hung outside the graduate coordinator's office, your advisor's office, outside the grad lab and on other bulletin boards around the Computer Science Department (5-6 copies are needed.) This all should be done at least TEN days in advance of your defense.

Your Defense: You should plan for your defense to take about an hour. I would recommend that you plan your talk to take 1/2 hour when you practice it. This will allow for nerves and questions.

The main part of your talk should be focused on what you did in your project, how you did it, the results and future work (like in your writeup), but make sure you provide enough background information for your audience, i.e., don't assume all the attendees have taken the same courses that you have. But, do make sure the biggest part of your talk is about your results/conclusions!

Another thing to keep in mind is that if you put algorithms and/or equations on your slides/overheads, you should discuss them not just point to them. I have some short articles/lists of things to keep in mind. Stop by if you'd like a copy.

Program Description
Fill in a brief, nontechnical description of what the program does. This should include an explanation of the results that are produced and, if appropriate, the algorithm or method used. Important assumptions made in solving the problem should also be described.

Input
Fill in the input data required by the program(s). This should include what values are required, what limits are place on the values, where and how they should be entered (the input format), the order in which they must be entered, and from what input device they may be entered. This is especially critical with very generalized program in which users may have to provide a great deal of data to customize the program to their personal needs. Also, if default input values are assumed, they should be specified here.(Include screen dumps of any GUI's and input menus where appropriate.)

Normal Output
Fill in the normal output of the program when presented with valid data. This should probably include an acuual outputlisting from the program along with explanatory notes for each value describing what it is, how it is to be interpreted, and in what units it is being presented. If your output includes graphical images, these should appear here.

Exception Reports
Fill in the exception reports. These are the error messages, warnings, or other abnormal output the program produces when it encounters invalid or suspicious data. For each error message, the manual should explain what causes that error and how users can repair it. Between "Normal Output" and "Exception Reports", every message, normal or abnormal, that could be produced by the program should be listed and explained.

Program Limitations
Fill in the program limitations. These are bounds or constraints inherent in the program itself that cannot be exceeded by users. Examples might include limits on accuracy (because of the physical characteristics of the computer), or maximum amounts of input (because of fixed ARRAY declarations).

Discuss system requirements such as memory and disk space needed, if known.

Command Sequence
Fill in the command sequence needed to execute the program(s) on a specific computer system(s). This will often be in the form of a listing of a complete input file ready for submission, or a sample terminal session.

If there are any special environment variables or other special conditions required, be sure to discuss these.

Author Information
Name: Fill in your name(s)
Address: Fill in your address
Telephone: Fill in your phone number. This is the information of the person(s) responsible for providing assistance.

Program Description
Fill in a brief, nontechnical description of what the program does. This should include an explanation of the results that are produced and, if appropriate, the algorithm or method used. Important assumptions made in solving the problem should also be described.

Historical Development of Program and Current Status
This includes the names and addresses of the original authors and anyone who had responsibility for program maintenance. List the order of modular development and modification. Describe testing criteria.

Overall System Structure
This will probably be displayed as a data flow diagram or some other pictorial representation.

Overall Program Structure
This will probably be displayed as a structure chart or some other pictorial representation. This shows how the individual modules and data structures are related to each other. (For object-oriented material, this would be in the form of a class hierarchy diagram.)

Description of Each Module
For the purpose of this course, this will be optional, but if your system is extendible and you envision you or someone else continuing to maintain this product, then include this portion. However, this info should be included minimally for each "program" (or class) in your system.

Every module contained in the structure chart above should be individually described in terms of its high-level structure. This should include:
a. Module name and type.
b. Author and date of completion.
c. Calling sequence.
d. Purpose.
e. Entry and exit conditions.
f. Assertions about program behavior.
g. Where it is called from.
h. What other routines it activates.
i. What data items are modified by this module.
j.Reference to the location of this module in the listing
k. History of changes/modifications to the original program.

Description of Key Data Structures
All important files and data structures should be individually described. This should include the following: (NOTE: Data abstraction is helpful here.)
a. Data structure name.
b. Purpose.
c. Operations of this data structure.
d. Underlying implementation.
e. Which modules access or modify this structure.
f. Reference to where in the listing this data structure is originally declared and initialized.

Built-in Maintenance Aids
If the program includes and debugging and testing aids or efficiency instruments for timing or profiling the code, the design document should include a guide to their use.

Testing/Acceptance Criteria
The technical documentation should contain a list of test cases to be used during testing of the individual modules and during system integration (optional).

Other

Complete Program Listing(s) should be included. These listings should include appropriate internal documentation, including source (if applicable) of and description of algorithms used. You may do this by providing the source on floppies OR in the case of web-based Java materials, by including the code in a separate src directory that is "submitted" to the instructor.

Makefile should be included.

Describe what computer systems, each part of the system runs on. Give locations of appropriate files.

Nan Schaller - Courses Page