Tutorial: Project evaluation criteria

This week focus is the criteria which will be used to evaluate your project work.  Part of the evaluation will be based on the software project itself; the rest will be based on the presentation.  I’ll deal with each of these parts separately.  The assignment for next week is to write a preliminary version of the on-line documentation file for your project, as described in more detail below.  Check this into the SVN repository by Friday, Feb. 1.

Before I get to that, here are some organizational details:

  • at tomorrow’s meeting we’ll discuss the contents of this post, with reference to a couple of example applications which I will demo.  I hope to have the pleasure of seeing at least one member of each team tomorrow morning.
  • I will also pass around a sign-up sheet for another round of appointments on Monday and Tuesday of next week (January 28-29) to discuss the progress of your projects individually.
  • Finally, if you intend to present your work in February, please notify me in writing, so that we can get serious about setting up dates for these talks.

Criteria for the software.  Here there should be no big surprises, as the criteria used to evaluate the software have all been introduced during the assignments which you have turned in during the semester.  Here’s the key points.  Pay special attention to the last two, as they are perhaps a bit new, although hopefully not surprising.

  1. The project itself should be a subclass of util.Assignment.
  2. On-line documentation. The project should include a html file as in our assignments (via the method getDocumentationFile()) which includes these three sections, listed below.  Note the I expect you to check in to SVN a preliminary version of this documentation by Friday, Feb. 1!
    1. The mathematical content of your project.  This should first of all “zoom in” to the specific domain of mathematics you are handling. For example, don’t just begin by saying, “We provide an application to identify the symmetry group of a wallpaper pattern”; rather begin by briefly reviewing the theory of symmetry groups on in the euclidean plane, and discuss how the classification of wallpaper groups can be mathematically described.  You should conclude this section with a single sentence describing your application as clearly and precisely as you can.
    2. Following this mathematical introduction, your documentation should then turn to the software implementation. How did you map the mathematical content onto the software platform you used?  Briefly describe the “flow chart” of the application, describing how you have implemented the mathematical content described in the previous section.  Mention any Java classes you have written, and any external packages or classes which play important roles in your implementation.  Indicate areas where you are satisfied with the results you obtain, and also those where you would work further if you were to continue on this project.
    3. User interface.  A description of the user interface of the program, preferably with screen shots showing the GUI (graphical user interface).
  3. User interface. How easy is your application to use?  Have you designed the user interface so that the user can experience the mathematical content in as simple and direct a way as possible? Have you taken advantage of the packages we have used so far in the tutorial (jReality, discretegroup, etc.)?  For example, have you used the appearance capabilities in jReality to help communicate the content of your application (colors, rendering attributes, etc.)?  Are the GUI components clearly labeled and neatly laid out? Does the documentation match the reality?
  4. Saving/restoring state.  One aspect of a successful user experience is the abillity to continue working after restarting the application.  That means, critical parameters should be saved (restored) when the application ends (starts up).  Use the methods  storeStates(Controller c) and restoreStates(Controller c) for this purpose.  I have extended gunn.Assignment2 to use these methods to store/restore its state; consult it to see how to do this for your own application.  These properties are saved off into a special file called the properties file for the application.  To be safe, you should specify a unique properties file for your project.  To see how to do this, look into the display() method of Assignment2, specifically, the JRViewer method setPropertiesFile().  Note that you do not need to specify a path for the properties file  if it is located in the same folder as the Java class of your application.
  5. Commented code.  Your Java code will not be put under a microscope and evaluated. At this stage, it’s more important that it works than how it works.  On the other hand,  I expect a minimal level of documentation in the source files:  Each method in your Java code should have a comment preceding it which describes what it does.

Criteria for Presentation. The talks are limited to 30 minutes.    It should follow the structure described above for the on-line documentation file.  There will be 15 minutes for discussion and questions. The best preparation is to understand and be able to talk about the mathematical content, the programming decisions you made, and how you would proceed if you were to continue with the project further.

1 thought on “Tutorial: Project evaluation criteria

  1. Pingback: 04.11 Next Lecture TODO List | Mathematical Visualization

Leave a Reply