Grading Overview

A total of 100 points is possible, but don't expect to get anywhere the total possible points --- the point guidelines include a lot of "headroom" for exceptional projects, with typical scores being 50-75% of the maximum in each category. Note that a single problem (e.g., inadequate documentation, or a program bug) can cost points in more than one category. For example, if the documentation is not adequate for using a feature, you won't get credit for implementing that feature, nor will you get credit for documenting a feature that doesn't actually work (you may instead lose points for inaccurate documentation). Likewise, if a feature is implemented but cannot be used because the program crashes, you won't get credit for implementing that feature.
These are generic grading guidelines I use for software projects. For projects selected by the instructor, there may be additional specific notes on grading. See the project description for those notes.

45 - Functionality

Functionality includes features used by all categories of user. Often this includes administrative users (sysadmins, etc.) in addition to end users. Functionality also includes performance scalability.

Robustness: 15

15	absolutely bulletproof
12	robust under reasonable use
8	minor bugs, works well enough to be usable
4	major bugs interfere with normal use

Feature Set: 15

15	WOW! Exceptional
10	All needed features and some pleasant surprises
7	Adequate for the intended purpose
2	Missing features interfere with normal use

Ease of Setup: 5 points

Setup often includes system configuration. Note that setup documentation is also scored under documentation. Missing, confusing, or erroneous documentation may cost points in both categories.

5	a snap to install
3	good installation overall; minor problems had simple and obvious
1	major difficulties installing
0	couldn't install

Ease of Use: 10

This category includes usabiliy for end users and for administrators. It is typically distinct from quality of documentation, but may include presence and usefulness of online help. Usability considerations for administrative users may be quite different than usability considerations for end users; both are considered here.

10	Couldn't ask for more
8	Quite usable, but could still be improved
6	Adequate usability, won't discourage normal use
3	Usability problems interfere with normal use
0	Unusable

15 - External/User Documentation

README.txt: 5 pts

5	very good README; complete overview with overview description and complete manifest including guide to other documents
3	adequate README, but either some inappropriate choices of what to put in or leave out minor organizational problems that make it less useful than it would otherwise be
2	README exists, but is misplaced, misnamed, or has flaws that limit its usefulness
0	README doesn't exist or is useless

User Documentation including installation and setup: 10 points

10	Professional quality documentation, easy to use as a tutorial or as a reference. Detailed installation instructions covering both normal and exceptional cases.
8	Good solid documentation for both tutorial and reference use, for all categories of user. Not quite professional standards, but very good for a short project.
5	Adequate overall, but some omissions or problems that could interfere with use.
3	Useful documentation for some aspects of the software but significant omissions or errors.
1	Not very useful, due to flaws, omissions, or poor organization.
0	No user documentation, or useless documentation

40 – Organization, Planning and Technical Documentation

Technical documentation and system organization are evaluated together. Good documentation can make a good design evident, and poor documentation can doom a good design to degradation over time, but good documentation cannot compensate for poor design.

Project Plan: 10 points

10	Report clearly indicates who did what, when they did it, and how long everyone spent on each of their tasks (assigned date and completed date, as well as time on task). There is clear record of when meetings were held, and what was accomplished and agreed upon at each meeting. A series of continually updated project plans continues to show all of the major project milestones and deliverables.
7	A plan was in place and followed. Some elements of the planning documents are missing or unclear. There is a record of tasks but it is not always clear exactly who did what and when or where the plan had to be changed and why.
3	A plan was in place and followed. Tasks and roles were assigned, but it is not clear who did what, when they did it, and how long everyone spent on each task (from assigned date to completed date, as well as time on task).
0	No final updated report of the project management is provided.

Systems Requirements (SRS & ConOps) – 10 points

10	Clear, complete, and well-organized description of requirements, including rationale for what is included, what has been deferred to the future, and (as appropriate) what has been excluded. ConOps provides clear user-centric specification. SRS provides well defined, precise develop and test-to specification.
7	Good description of requirements. Some minor problems, but completely adequate as a guide to future developers. Shows clear understanding of the roles of the ConOps and SRS such that the right kinds of information appear in each. Reasonable expectation that others could use the document for maintenance or system creation.
5	Fair specification of requirements. Some kinds of requirements are missing or are put in the wrong document. Shows uneven understanding of how to write effective requirements or the roles of the requirements documents. Useful to maintainers and others but would probably require some support.
2	Requirements are barely adequate for project use. Missing significant parts or shows significant misunderstanding of how to write effective requirements.
0	Requirements statement is missing or inconsistent with the product; not useful to future developers.

System Architecture and Design Documentation - 10 points

10	Well organized system, clearly described with clear breakdown of system into major parts. Good design documentation, adequate for maintaining and extending the system. Most changes that might be anticipated would be easy, and the documentation of each part of the system is adequate.. Documentation includes some anticipated changes for future versions of the system.
7	Adequate organization and design documentation, with some things that could be improved. Some changes may be more difficult to make than they should be.
3	Some major problems in design documentation, or some things that should be localized or easily configurable are inappropriately hard-wired in the application.
0	Technical documentation is inadequate, to the point that the only practical way to determine how to make a change is to read the source code.

Detailed Technical Documentation - 5 points

This can be any combination of external and internal documentation (e.g. JavaDocs), and applies to both conventional source code (e.g., Java) and to other artifacts such as Makefiles, page templates, etc. This is primarily an evaluation of usefulness of the documentation, not raw volume, and necessarily includes factors such as coding style.

5	Exceptionally well documented and readable... easy to read and modify.
3	Well documented, but could be better in places.
1	Inadequate documentation or serious impediments to understanding.
0	Seriously inadequate or misleading documentation.

Presentation: 5

5 Does the presentation show key lessons learned and the application of lessons from class.

Project Grading