Project 4 Grading Criteria

Project 4 Grading Criteria and Comments

Below are the criteria that were used to grade Project 4. We also mention some common mistakes that people made and should try to avoid in future projects, in other classes or in the workplace.

Usability <10 points total> Graded by Greg. Email him with questions.

A __/2 Clean interface/directions * The directions on how to use the system are clear and intuitive.

B __/2 Image handling * Able to upload and display images for signatures and letterheads.

C __/2 Address Verification * 1 point for everyone, one more point for actually verifying the address.

D __/2 Error handling * You lost points here if your application gave unmasked errors.

E __/2 Message notification and display * Check if the message was delivered and viewable by the recipient.

Common problems:

Many projects simply didn't work and had a critical error or crash somewhere in the process of writing or sending a letter.
If you have a large, complicated form on the web, you should always:

1. make it obvious what is required
2. make it easy to see what has been incorrectly filled out
3. make it easy to modify entries if they are incorrectly filled out.

If an HTML form asks for data in format "xyz" (for example "mm-dd-yyyy"), then make sure you explain what the format is, and then make sure your code actually expects it the same way you require it from the user!
If an address is incorrect, you should consider the option of accepting it anyway, in case the address verifier doesn't know everything.
You should make clear the requirements for your application. For example, if your application requires Internet Explorer 6.0, you should tell that to the user.
You should always catch errors in your application, so that they are handled gracefully.

Code quality <10 points total> Graded by Joe. Email him with questions.

F ___/2 Comments (especially for difficult code)
G ___/2 Clarity (variable names, code structure, flow of control)
H ___/2 Modularity (using functions, and not reinventing PHP functions)
I ___/2 Error handling (sufficient error checking)

J ___/2 Organization (use only a sufficient number of files, and avoid useless files; this includes making sure SOAP was organized and implemented properly)

Common problems:

Even though the SOAP part of the project was challenging, some students did not make an attempt to build the SOAP interface at all, which is not good.
Sometimes it is good to have a comment header at the top of every file, not just at select places within the code.
Aim for simplicity when designing and organizing software.
Although code should be modular, do not create so many functions that it is difficult to understand the navigational flow. Every file within the directory should be used in the implementation, otherwise remove it. That not only makes for better software design, but it also makes it easier for us to grade!

Report <10 points total> Graded by Victor. Email him with questions.

K __/2 Good grammar/spelling/language. You should use complete sentences, correct spelling and grammar, and avoid colloquial language and slang.

L __/2 Well-structured document. It should be easy to find information in the document.
M __/2 Addresses the major design decisions (security, authentication, privacy, database design).
N __/2 Offers good solutions to the problems addressed, in a way that is understandable and reusable
O __/2 Technical correctness. Do not make statements that are incorrect!

Common problems:

The purpose of the report is to describe the technical decisions you made, and how you did your implementation. Several people spent far too much time discussing the interface of their site, as if the report was a user's manual.
At a minimum, you should discuss your decisions about security, session handling if any, your database schema, and scalability. Many groups left out one or more of these issues. You should also explain how your group solved the problems presented, and why.
Be sure to understand the the meaning of modularity. Modular programming is a style of programming in which the complete program is decomposed into a set of modules (components), each of which is manageable in size, has a well-defined purpose, and has a well-defined and restricted interface to other modules. Just using functions is not equivalent to modular programming.
You should write well in the reports. The goal is to convey technical information. That means you should use enough structure (headings and lists) to make the document navigable. The document should be polished, with no grammar or spelling mistakes. Do not write in a chronological style (e.g. "we tried X, but then we decided to do Y"). Instead, write in a logical style ("X is better than Y for the following reasons.")
When using figures or diagrams in your reports make sure you have some text that accompanies it. This can be a simple caption that just gives a basic description of what is shown. Figures can be a very effective way to clearly present high level information, and should be used when appropriate.
Strong personal opinions do not belong in a technical document, and self-praise is often immature. There is a fine line between self-esteem and self-delusion. Be objective.