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.

Points

50 - Functionality Functionality includes functions used by travelers (finding a bus route) and functions used by the webmaster or site administrator and staff, such as entering and modifying bus route data. 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: 7
		* 7 = a snap to install - on a par with highly automated installers
		* 5 = easy to install
		* 3 = a little cumbersome, but installed without major problems
		* 1 = major difficulties installing
		* 0 = couldn't install
	Ease of use: 13
		* 13 = couldn't ask for more
		* 10 = Quite usable, but could still be improved
		* 8 = Adequate usability, won't discourage normal use
		* 4 = Usability problems interfere with normal use
		* 0 = Completely unusable
30 - External/User Documentation
	README (README.txt or equivalent OBVIOUS orientation document): 7 pts
		7 = complete overview with overview description and complete
		manifest including guide to other documents
		5 = very good README
		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 has flaws that limit its usefulness
		0 = README doesn't exist or is useless
	Installation/setup docs (complete? easy to follow?): 5 pts
		5 = Excellent docs for both common and uncommon cases
		3 = Adequate installation documentation, but could be improved
		(e.g., for less common cases)
		1 = Major flaws or omissions in installation documentation
		0 = Missing or completely misleading installation documentation
	User docs - tutorial/reference: 18 points For the bus route finder system, much of the user documentation is for the site administrator and staff. A very rough breakdown is 5 points for traveler documentation (probably on-line), 13 points for documentation for site administrator and staff on matters such as how to update and test the bus route database, how to edit the fixed parts of web pages, etc.
		18 = really professional standards, on a par with the best commercial software
		15 = Good solid documentation for both tutorial and reference use; not quite
		professional standards, but very good for a short project
		9 = adequate user documents for both tutorial and reference use
		6 = not very useful, due to flaws, omissions, or poor organization
		3 = barely useful at all
		0 = no user documentation, or useless documentation
20 - Internal/Technical Documentation Color Evaluation of technical documentation also involves some evaluation of the organization of the product itself. 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. (See also: Change scenarios.)
	Architecture/design overview - 5 pts
		5 = Excellent overview with clear breakdown of system into major parts clear description of criteria for breaking into subsystems (e.g., it would be obvious where code for a new feature should go) abstract understanding of program behavior If the architectural overview is first-rate, it should be adequate to quickly answer questions about which parts of the system would be affected by particular changes.
		3 = Adequate overview, good first step indicating where to look for relevant parts of the system
		0 = No overview, or useless overview
	Technical documentation as a whole - 15 pts (may include external and internal documentation, diagrams, Javadoc, etc.)
		15 = Exceptionally complete and useful design documentation; with a small amount of study I could easily port, extend, or modify the system. The system is organized in a way that makes it exceptionally easy to extend or modify, and each part of the system is specified precisely enough that it could be modified or replaced without studying other parts of the system. Anticipated changes (e.g., features or generalizations that did not make it into version 1) are clearly documented. 10 = 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. Some changes may not be quite as localized as one would like, but non-localized changes are reasonably simple, and the documentation is adequate to determine what must be changed. Documentation includes some anticipated changes for future versions of the system. 7 = Adequate design documentation, with some things that could be improved. Some changes may be more difficult to make than they should be. 5 = Some major problems in design documentation, or some things that should be localized or easily configurable are inapropriately 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.

Change Scenarios

Evaluation of usability, documentation, and system organization may involve the following change scenarios, depending on time and other problems encountered.

Graphic Design

The graphic design of web pages displayed by the system should be easily configurable by the system administrator. For example, if the system is adopted by the Portland Tri-Met system, it should be easy to adopt a web page style consistent with the Tri-Met site. Changing page design should not require programming or reading programs.

Multi-lingual Site

The bus-riding population speaks many languages, and an English-only site does not serve them as well as a site that offers two or more language versions of the site. Creating a multi-lingual version of the bus route finder system may be more involved than simple changes to the graphic design of pages, but it should not be too difficult, and the technical documentation should be adequate for determining how it could be accomplished.

Other

There may be other change scenarios that are not described here (so it is not adequate to simply cover the particular listed scenarios).