Project Guidelines and Checklist

Which software are you extending?
In many cases, you will be extending or using existing SIP or RTSP applications: rtspd, sipd, siplib, sipum, and sipconf.
List the features you want to support, indicating the priority of each (must, should, if time).
You should be very careful in committing to (to be)supported features and distinguishing between MUST, SHOULD and MAY. We will discuss the features based on your background and interest. The features will be prioritized based on the available time-frame and other dependencies.
Which existing libraries or modules will you be using?
Some projects may need to use the existing libraries, e.g., siplib. We strongly encourage re-use of existing tools and utilities. This avoids repeating the same set of mistakes over and over. Most of the external dependencies will be identified in the begining, but students are encouraged to find out more about existing tool kits that can be used. The world wide web is an excellent source of many tools and utilities, e.g., XML parser, HTTP client library, etc.
Programming language(s)?
Often, the programming language is given by the existing software. However, we prefer you use the programming language of your choice. In the past people have used C/C++, Java and Tcl. Please note that we do not accept any Microsoft'ism, e.g., MFC, unless the project itself is about developing an MFC module. This is true for any other proprietary extensions by other vendors. We have various utilities and tools that allow you to use Unix like standard functions (like pthread) on Windows, instead of using Windows extensions (e.g., CreateThread) directly. For cgi-bin, we prefer Tcl or Perl. PHP, Java servlets or JSP are also possible for web-based systems. No ASP.
Which operating system platforms do you plan to support?
For C/C++ projects, at least one of the standard platform should be supported: Linux, FreeBSD, MacOS or Windows 7. For some projects, e.g., WinCE, this may differ. Most of the existing code works on all of the standard platforms, so you should try to support as many of the platforms as possible.
If applicable, what GUI tool kit will you be using (e.g., Tk, Java AWT, Java Swing, Windows, Qt)?
Some projects may involve GUI components, while others are servers or only have commandline interfaces. Finally, some projects are cgi-bin scripts or servlets. As far as possible, we will try to divide the project into two parts: a GUI-independent library and GUI application (or command line application). The interface between the two MUST be well defined and documented. The choice of the GUI tool-kit is up to the students, with Java Swing and Tk the preferred choices, due to their platform-independence. Any cgi-bin, JSP or servlet program must be compatible with a modern browswer. Standard HTML cleaned up and tested with tidy, rather than Microsoft Word-generated HTML, must be used.
How will you do component testing?
Test tools?
How is error logging to be implemented, if applicable?
Most of the server applications are required to log error and access information. We have utilities in C/C++ to allow a more high level interface to error logging. All command line applications are required to provide a -v command line option to allow verbose mode, in which all the debug and trace prints are printed out. If the -v option is not specified, then only the required error logs and notifications should be printed, and no debug or trace information.
What will be the installation mechanism (e.g., 'make', InstallShield, wrapper, tar file)?
Installation is part of the evaluation of the project.
List milestones for your project, i.e., dates and what functionality will be available at that time or what you will have accomplished ("familiar with RFC").
Once the features list is finalized, we make a schedule describing major milestones and dates to accomplish them. You are responsible for providing input while finalizing the schedule. You should consider different aspects like familiarity with the domain, socket programming experience, other course work, personal commitments, etc. The list of major milestones will be finalized at the begining. This will be reviewed every other week. There should be a verifiable milestone at least every two weeks.

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.
 cvs -d 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.

Last updated by Henning Schulzrinne