If you are writing code in C/C++, then your code must confirm to the coding guideline. Slight conscious deviations may be tolerated but must be discussed with the mentor in advance. Lack of time is not an excuse. doc++ should be used for documentation.
If you are writing code in Java, then you MUST use javadoc to generate documentation of any API. Conscious deviation may be tolerated but must be discussed with the mentor in advanced, e.g., if you are extending the existing Java code with modifications spread throughout the existing code.
To have consistent progress throughout the semester (rather than doing most of the work in last two weeks, when you have five other homework submissions due), we will have meetings very frequently. For a semester project, the group or the individual will meet me twice a week for the first one month. Then once a week for next one month. Depending on the progress the meeting will be once a week or once-two-weeks for the last month. Meeting time is fixed based on your and the mentor's convinience every week. It can be different from week-to-week. The purpose of the meeting is to closely monitor the progress of the project. It is more frequent in the begining since that is when you may encounter more problems. During the meeting the original schedule is compared against the actual schedule. A slip of one week is a yellow signal, and requires some additional work from your side the next week. A slip of two-consecutive weeks is a red signal and requires significant work from your side the coming week. The color must be changed to yellow in the next week. If the slip lasts for three weeks then it will affect your final grade. Note that when a slip-of-a-week occurs, the schedule is shifted by one week. So it is not as difficult as it sounds.
If you are a CVN student and you can not make it for every meeting, then we will have telephone meetings. But you should be prepared to visit in person at least once every two weeks. Note that CVN students are expecteed to put in the same amount of work as on-campus students, about 3 hours per week per credit hour registered. Saving up the project for last two weeks of the semester is not acceptable. We will ask you to drop the project if you have not made progress according to your schedule.
If you decide to drop the project please consult the mentor and the advisor in advance. If the reason for dropping is "it is too tough for me", we can always find a work-around or find some other appropriate part of the work which is more interesting and easy, or find more students for the project or reduce the supported features.
If you are extending an existing software then you must use CVS. It allows you to be in sync with the current development and prevents re-discovering the same bugs. Contact Henning Schulzrinne to give you CVS access. Once you have the CVS access you can use the following command to checkout the cinema code.
# Replace kns10 by your userid. export CVSROOT=:pserver:email@example.com:/home/hgs/src/cvsroot cvs -d :pserver:firstname.lastname@example.org:/home/hgs/src/cvsroot login ... # You will have to enter your password cvs checkout cinema ... # This will create the directory structure for cinema. # To update or "freshen up" your files with the latest # version in the CVS tree cvs update -dP # Note that adding or committing affects other users also # so you must be very careful and inform me before adding # or commiting a new file. # # to add a file cvs add foo.c # To commit a file cvs commit foo.c # To commit the whole sub directory cd <directory> cvs commit
If you are using an existing software, rather than extending, then you may not need to use CVS.
A mid-term project review is held during (approximately) the mid-term exams week. You may prepare slides (power-point or PDF), but is not required. The purpose of mid-term review is to let the faculty know where we stand and whether we would be able to finish the project in the time frame or not. If you have a partial demo-able system you should show that during the mid-term review. The duration is typically half-an-hour per project.
Towards the end of the semester you will be required to show a final demo of the working system. Usually the demo is shown in the CLIC lab or the IRT lab. If you have problem with the place, please talk to the mentor in advance.
At the end of the semester, after you have completed your project, you will be required to submit an HTML project report as per the prescribed format. Project reports produced by Microsoft Word are not acceptable, even if exported to HTML. If your project involves developing a standalone client or server for which some kind of user manual is needed then you are required to provide a user manual. An example manual page format is here. If your project does not fit into this format, we will discuss another user-manual format as needed.
Project must be packaged as a tar.gz file, with a README file containing installation instructions that clearly identifies any other hardware and software needed. If you have another installation documentation (e.g., HTML file or install shield) then you must mention that in this README file. You MUST submit all of your work, including any test routines and inputs and outputs, any executable, source code and documentation. You may be asked to unpack and install the software. Significant deviation from what is documented may affect your grade. You must provide both the source code (with build instructions) and the binaries with executables and libraries, if any.
If your project involves extending the existing software and you are working in the CVS then it is required to integrate your work into the existing software. This is true for small projects which modify only part of the existing software. You can update the existing documentation instead of submitting another document and manual page. If your project is integrated with the existing software into the CVS then you do not need to package it as a tar.gz file.
If you are unable to finish the project or to finish some features of your project, please do not panic. Things are flexible and we would be glad to discuss alternatives. In very rare circumstances it may be possible to give an "incomplete" grade for the current semester, so that the student can work on the project and complete it the next semester, say within couple of weeks. Please note that this option is considered only in rare cases and only when the students are sufficiently motivated and skilled to finish the project in a couple of weeks time frame, but could not do that before the semester ends.
The mentor will check for code quality, including:
Grades are given by Prof. Henning Schulzrinne and not by the mentor, but the mentor is consulted in the grading.