|
Project evaluation guidelines
|
|
Project evaluation guidelines
Course projects will be evaluated by looking at the set of artifacts produced over the course of the quarter.
Project presentations (project proposal, midpoint review, release announcement) are important for conveying
information, but will not be the focus of the evaluation.
Projects will be evaluated in the following dimensions: Released product, team process, code quality, and design and
process documentation. To facilitate evaluation, all documents should be organized on-line in a manner that is
accessible to the instructor and the TA. Source code should be included in this collection of documents. The
collection of documents should be presented in a way that it is easy to navigate. In addition, a small amount of
this documentation can be submitted as hard copy (but not more than 20 pages).
Released product
The quality of the released product will be assessed by having a number of users work with the application. We plan
to involve independent evaluators in the process. Users will begin by installing the application, and then testing
it on the key scenarios (as defined by the user documentation). Users will evaluate ease of use and functionality.
Defects will be noted.
Code quality
Code quality will be assessed by inspection and looking at associated documentation. The code will be evaluated on
whether or not it would be a valuable addition to the companies code base. Does the code look like it will be easy
to maintain and extend. Is it possible to understand how the code works by looking at the code and the
documentation. Does it follow reasonable coding guidelines. (You can choose your own guidelines, but you should
identify where they come from.)
Team process
How well did the team work together. Did it meet deadlines? Were all team members engaged in the project and
contributing to it. Were reasonable processes followed, such as tracking bugs and requirement changes. Was there
an effective use of software tools. You can think of this part of the evaluation as being done my management to
determine if this is a team that they want to keep together for future projects.
Design and process documentation
Does the project documentation tell the full story of the application, from conception to release? Was each stage
properly documented. What were the initial user studies and use cases? How were these translated into functional
requirements and architectural design. Was a scheduled created and followed? Was a risk analysis conducted. Is
there documentation from the testing/QA processes - both bug tracking, as well as test cases and metrics.
|
 |
Department of Computer Science & Engineering
University of Washington
Box 352350
Seattle, WA 98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX
[comments to anderson]
|
CSE Home