CMSC 341 Project Policy


Grading Policy:

Projects will be graded on five criteria

  1. Correctness -- does the project produce the correct results, adhere to the project specification and follow the project organization rules for the course.
  2. Design -- does the code follow good OO design criteria and follow the design and implemenation guidelines for the course
  3. Style -- does the project adhere to the course guidelines for coding style?
  4. Documentation -- does the project adhere to the course guidelines for documentation?
  5. Efficiency -- Does the code use the most efficient algorithms and data structures? Does the executable meet the specified running time for the project?
This means that turning in a project that "works" but is poorly organized or poorly documented or is noticably inefficient will not receive full credit. An exceptionally good job will receive extra credit.

Any project that does not create an executable for any reason will lose all points allocated to the "correctness" criterion. Use the tools available to you (i.e. submitmake and submitrun) to be sure that your makefile and source code will create an executable.

Each project grade will broken out in a grading sheet that is specific for that project. The following are guidelines that give you some idea of the project grading scale.

  1. 111 - 125%: An incredibly good job of the type that comes along only rarely. The instructor must approve any instance in which the grader recommends a grade in this range.
  2. 101 - 110%: A project submittal that exceeds the standard expectations. The project must show additional work beyond the requirements or must use especially elegant or advanced methodologies.
  3. 100%: The submittal satisfies all the requirements. A well-organized and well-documented project with good design and implementation.
  4. 80-99%: A submittal that meets the requirements for the assignment but with a few small problems.
  5. 70-79%: A submittal that has many small problems and/or falls slightly short of the requirements.
  6. 50-69%: A submittal that has serious problems and/or falls significantly short of the requirements. Serious problems would include failure to document, poor organization, or incorrect results.
  7. 30-50%: A submittal that has extremely serious problems but nonetheless shows some effort and understanding. An example of an extremely serious problem is failure to compile.
  8. 0-30%: A submittal that shows little effort.

Project Grade Changes

All projects are graded by your instructor. Visit your instructor during regular office hours (or make an appointment) to request a project grade change when you think a mistake has been made.. Come prepared to show evidence of the specific mistake. Project grades will not be changed just because you think too many points have been deducted.

Remember that if you have a question regarding your project grade, you have exactly one week from the receipt of your grade to contact your instructor.

Project Regrades

In some unusual circumstances you may recieve a low project score because of a single, simple error that results in many incorrect outputs or results in a compiler/linker error. The definition of "simple error" is determined by your instructor. In such cases, your instructor may (at his discretion) allow you to fix the simple mistake and have your project regraded.

Please note that tools such as "submitmake" and "submitrun" are provided for your use so that you can verify that your project is working correctly after it has been submitted. In particular this means that the statement, "It worked in my directory" will carry little weight.

A 10-point deduction is assessed when your project is regraded.

Running on Linux

Note that your project will be graded by being compiled, linked and executed on the LINUX GL system (not IRIX) using the /usr/local/bin/g++ compiler. Be sure that you compile and test your project under LINUX. Compiling it and testing it under IRIX, Windows or any other operating system with a compiler other than g++ does NOT guarantee it will perform properly under LINUX.

Hints for enhancing your grade:


Do submit partial work for partial credit. A zero grade is much worse than a low non-zero grade.
If you think you should receive extra credit, let the grader know by submitting a file named grader.README that briefly describes why you should get extra credit.
Do check your submittal by using submitls, submitmake, and submitrun. These are explained in detail
below.

Due Date:

Every project has a firm due date. You should budget your time to complete your project and submit it by midnight of that date. Since you can submit material multiple times, we use the time of your most recent submittal.

Be careful. If you attempt to submit something after the due date, all previous submittals will be counted as late. The date of the last submittal you make is taken as the submittal date for all your materials. Please don't attempt to submit any files after the due date.

There is no such thing as a late penalty. If your project is late, it will receive a grade of zero.

Extensions will be given only rarely and only in the most dire circumstances. Your chances of getting an extension diminish rapidly as the due date approaches. Only the instructor can give an extension.


Cheating:

Cheating in any form will not be tolerated. Instances of cheating may be reported to the UMBC Academic Conduct Committee in accordance with UMBC Student Academic Conduct policy. These reports are filed by the Committee and can be used for disciplinary action such as a permanent record on your transcript. Academic honesty is absolutely required of you. You are expected to be honest yourself and to report any cases of dishonesty you see among other students in this class. Reports of dishonest behavior will be kept anonymous.

It is your responsbility to read, understand and adhere to the Student Honor Code If you ever have a question about cheating in this course, please ask the instructor about it. Ignorance about the cheating policy is not a defense after the fact. Your project assignments are to be entirely your own. You may discuss general course ideas with others, but everything you submit must be just your own work.

It is never permitted to copy code from someone else nor to provide code to someone else. This applies to paper and electronic forms of the code. Help received from the CSHC, TA, or instructor may be included in your submittals.

Here is a general rule for you to follow:

Having someone else's work in your possession or giving your work to someone else in any form, even briefly, is dishonest.

You must protect your materials from observation by others. It is your responsibility to maintain your course files so they cannot be read by others. Failure to protect your course files will be considered to be a form of academic dishonesty. In particular, do not store your files in a publicly-accessible directory. If your materials are copied by another person because you failed to protect them, you will be subject to the same disciplinary action as the other person. If in doubt about how to protect your files, ask for help in a UCS lab, at the CSHC, or from the TA or instructor.

We will be using special software to check for cheating. The software is quite sophisticated and can detect most instances of cheating. It will be used to check each and every pair of students for every project, even across sections.

The penalty for violation of this policy is

  1. a project score of zero
  2. semester average reduced by 10% (one letter grade)
  3. actions reported to the Academic Conduct Committee

Checking Your Submittal:

You should check that your submittal is complete and works as it should. It's easy to forget to submit a file. Also, you may have an execution situation in which your project works in your directory but not in the grading directory.

There are three tools available that allow you to check your submittal. These are submitls, submitmake, and submitrun. It is your responsibility to use these tools to check your submittal.

Don't waste all that work you did on your project! Make sure you have submitted all the required files! Make sure your submitted project compiles successfully! Make sure your submitted project executes successfully! Use the tools provided to you!

submitls allows you to list the files in your submittal directory. Documentation for submitls is on the web at http://www.gl.umbc.edu/submit/.

submitmake, and submitrun are in the directory /afs/umbc.edu/users/d/e/dennis/pub/CMSC341H/. You can use these programs to make or run your submitted projects in your submittal directory, just like the graders will do.

The syntax for submitmake is similar to that for submit:

submitmake <class> <project>

Example:  

/afs/umbc.edu/users/d/e/dennis/pub/CMSC341H/submitmake cs341h Proj1
This makes the project, and shows you the report from the make utility. It cleans up the directory after making the project (removes .o and ii_files), but leaves the executable in place.

The syntax for submitrun involves command-line arguments, if any, for the project.

submitrun <class> <project> [command-line args]

Example:

/afs/umbc.edu/users/d/e/dennis/pub/CMSC341H/submitrun cs341h Proj1 chess chsfile

This runs the project, assuming there is an executable named Proj1 (i.e. submitmake was run successfully). In this example, the file chsfile would be in the directory from which you invoke submitrun, not in the submittal directory.