CIS 422/522 Software Methodologies
Project Grading Criteria

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
	Robustness: 15 points
		15 = absolutely bulletproof
		12 = robust under reasonable use
		8 = minor bugs, works well enough to be usable
		4 = major bugs interfere with normal use
		0 = doesn't run
	Feature Set: 15 pts
		15 = WOW! Exceptional
		11 = All needed features and some pleasant surprises
		6 = Adequate for the intended purpose
		2 = Missing features interfere with normal use
	Ease of setup: 5 pts
		5 = a snap to install - on a par with highly automated installers
		4 = easy to install
		3 = a little cumbersome, but installed without major problems
		1 = major difficulties installing
		0 = couldn't install
	Ease of use: 15 pts
		15 = couldn't ask for more
		11 = Quite usable, but could be improved
		6 = Adequate usability, won't discourage normal use
		2 = Usability problems interfere with normal use
		0 = Completely unusable
20 - Final SRS, SDS, and Project Plan
	Final Project Plan - 5 pts
		5 = 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). A process was in place to have each group member's task completion verified and initialed by another group member. There is clear record of when meetings were held, who attended, who arrived significantly late, the agenda, 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.
		3 = A plan was in place and followed. Tasks and roles were assigned, but it is not perfectly 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.
	Final SRS and SDS - 15 pts
		This document should include an updated SRS and SDS, as well as additional detailed technical documentation that would be required to fully understand, modify, and extend the system. YOU MUST SUBMIT YOUR ORIGINAL, GRADED AND MARKED-UP SRS, SDS, and Project Plan WITH YOUR FINAL PROJECT.
		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 this version) are clearly documented. The SRS has been updated to reflect how the requirements have evolved, and the SDS has been updated to reflect the updated SRS. The SDS matches what was actually built and turned in. All source code is well-commented.
		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.
15 - External/User Documentation
	README.txt: 5 pts
		This should be a text file, submitted with the source code, explaining what are the files being submitted, who are the authors, the class name and assignment, and what needs to be done to both compile the source code and run the program. The file should still work a year from now, in case a future 422/522 instructor is given a directory containing these files. The file should list the version of the compiler and any other software that was used, and any additional setup that may be required.
		5 = complete overview with overview description and complete manifest including guide to other documents
		4 = 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
	User docs - installation/tutorial/reference: 10 pts
		This should include everything a user needs to install and use the system.
		10 = really professional standards, on a par with the best commercial software
		8 = Good solid documentation for both tutorial and reference use; not quite
		professional standards, but very good for a short project
		6 = adequate user documents for both tutorial and reference use
		4 = not very useful, due to flaws, omissions, or poor organization
		2 = barely useful at all
		0 = no user documentation, or useless documentation
15 - Initial SRS / SDS / Project Plan
This is the first deliverable for the project. The 15 points are distributed among the three components.
	Project Plan - 5 pts
		5 = Solid, well-thought-out and agreed-upon plan for proceeding with the project. A milestone is associated with every major activity. The project management demonstrates a well-justified and deliberate decision to follow a specific software development process. Clearly identified channels and means for communicating and maintaining a shared knowledge base. Well-defined tasks and roles, and an internal documentation system for accounting for who does what. Your group is able to clearly communicate all aspects of the project and its management. 3 = A good build plan is determined and followed. Tasks and roles have been assigned. But no one is really sure what other folks are doing, and how they are progressing with their tasks. 0 = No clear management in place. Things get done when they get done. Tasks may be assigned, but there is little or not documentation tracking who is doing what, and when it gets done.
	Mini-SRS - 5 pts
		5 = Clear motivation for the system, problem statement, description of what the system will do, Clear description of the user, what they will expect, what they will know, and their current technology usage patterns. Realistic and detailed scenarios describe all possible major interactions with the system. Sufficient measurable functional and non-functional user and system requirements. The document can be easily updated and maintained as requirements change.
	Mini-SDS - 5 pts
		5 = A clear breakdown of system into major parts, description of criteria for breaking into subsystems (e.g., it would be obvious where code for a new feature should go), and abstract understanding of program behavior. System structure and control model are clear. Subsystems are sufficiently detailed so that a programmer could take this document and start writing code. Models are provided for each major subsystem, showing the design from a number of different persectives. Rationale is provided for all major design decisions. The document can be easily updated and maintained as the design changes.

A.Hornof, Winter 2001. Adapted from materials created by Michal Young, Spring 2000.