Evaluation Criteria for Senior Projects

Department of Mathematics and Computer Science
September, 1997


Introduction

The following presents documentation and presentation requirements for the senior project in computer science, provides a schedule for required documents, and explains how projects will be evaluated and how a grade for them will be assigned. Although the documents written for the senior project are similar to those produced as a part of a software engineering project, for us they serve an additional function. For most students, this project will be the largest and most complicated of their academic experience. The documentation you produce should reflect the effort that goes into your project so that your teachers can assign a fair grade. In evaluating your project your teachers can rely only in part on your presentation, and will rely substantially on the documentation you provide. For that reason, it is important that your documentation provided be clearly organized and well written. During your project you will meet on a periodic basis with your supervising instructors. One of them will have primary responsibility for your project and should meet with you at least once each week, and a second will serve as a second reader for your project and may not meet with you as frequently. Both will be responsible for independently assigning a grade. It will be your responsibility to meet frequently with your supervising instructors and to set up meetings with them.

Required Documents

The following documents are expected of any senior project. Your project may require additional documents - for example, if your project requires the writing of a substantial body of code in some language, your documentation set would probably also include a test plan, source code, and test results. Because of the variety of projects that students undertake for the senior project, your supervising instructors will have some flexibility in deciding the format of these documents and in asking for additional documents if appropriate. These requirements should be set at the start of the project. You should decide on some form of configuration control for the documents produced by your team. Each document should include a revision history indicating the changes made to the document and the reasons for them. When configuration control begins depends on the document. For the proposal and requirements documents, configuration control begins when the client has approved the initial document, and any changes should be made with the client's approval. With the remaining documents, configuration control should begin when the document goes into use (as, for example, the design document). A schedule for the delivery of each document will be set in discussions between the project group, the client, and your supervising instructor.

Proposal

The proposal should be a clear statement of the problem and requirements for its solution (i.e., this should be considered as a requirements document). It might take the form of a memo written to the client describing the group's understanding of what needs to be done, and should, in any case, include a place for the client's signature indicating that the proposal has been read, understood, and agreed to.

Requirements Analysis

The project group should evaluate the requirements document and propose three alternate approaches to a solution of the problem, with the advantages and disadvantages of each approach clearly described. If possible, the project group should make a recommendation, but it should be up to the client to make a final decision. This document should include a section for the client's decision and approval signature.

Design

Senior projects will vary greatly in the tools they use to solve the problem before them. Some projects will require significant amounts of programming, some will include the design and implementation of a database, and others will build a system from other tools. Since this document will differ from group to group depending on the problem, the approach, and the tools used, the form of this document will be set in discussions between the project group and the supervising instructor.

User's Document

It is expected that a group project produce a system which will be used by your client. The user's document should explain clearly to a non-technical user what the system can do and how to do it.

Maintenance and Installation Document

It is expected that over the useful life of the product it will be necessary to make changes to it. It may also be necessary from time to time to rebuild it. This document should describe all of the parts of the system, how they fit together, and how the system can be reconstructed from its parts. If the project requires some programming (but is not primarily a programming project), then this would be a good place to place annotated program listings. It would also be a good place to place descriptions of Oracle forms, reports, and menu descriptions. For projects that are primarily programming projects, however, separate documents may be more appropriate for code listings.

Meeting Logs and Journals

Each meeting of the project group should be minuted (who was there, what issues were raised, what decisions were made). The minutes should be formal, and should be collected in one document. Each member of the project group is asked to keep a journal throughout the project either as a spiral notebook or a document on a computer. It should contain a weekly time sheet of your time spent on the project. List your work by categories (design, requirements, writing, meetings), and say (roughly) how much time was spent on each task. In addition, your journal could contain your own thoughts about the project. These can be divided up into technical musings (explorations of alternate design options, etc.) to your own reactions to the project (this week things went really well/rotten, etc.) The journal may contain anything else you want to add. Your instructors may read your journals, but we will not pass them on to anyone else. If there are parts of your journal that you would prefer that we not read, paper-clip the appropriate pages together with a note.

Client sign-off

This should be a brief, one-page document signed by your client saying that the project was completed satisfactorily. There should be an opportunity for the client to note things that need more work, and things the client would like to see added (this may form the basis for another group's project).

Project evaluation

This section should be your group's evaluation of the project. You should describe what worked, what did not, how problems you encountered were or could be corrected, and how your project could be extended. It is important that this section be both thorough and comprehensive.

Final document submission

Although drafts and final copies of individual documents will be called for throughout the semester, all of the documents except for individual journals will be submitted near the end of the term in bound form (check with the print shop for options) with a cover page, a table of contents, and a description of the overall project. Any code segments produced as a part of the project (programs, PL/SQL segments, etc.) should be included as appendices. We will need three copies - two for your readers, and one to be placed in the Mathematics reading room library. While submitting this third copy is at the option of the software group, it is highly useful for students considering what projects to do and wanting to get an idea of what such a project entails. In this third copy, please include just after the title page a page, signed by everyone in the group, giving permission for the use of the document in the Math/CSci reading room.

Formal Presentation

You will be asked to give a formal presentation on your project. This should be about 20 minutes in length followed by a period for questions and answers, and will be attended by your teachers, clients, and fellow students. This should be primarily in the form of a product presentation, but feel free to include discussion of some of the problems faced and how they were resolved.

Evaluation Criteria

Your project will be evaluated against the following criteria\footnote{These criteria are adopted from those used in software engineering projects at the University of Wales, Aberystwyth

Quality of product: 40 points.

Your readers will make an overall assessment of the quality of your project including how much was achieved given the level of difficulty of the project, the quality of the program, and the quality of the user interface. For a group project, this will include an assessment on how well you were able to work together. This includes how well tasks were allocated and problems resolved. This will be an assessment of how professional you were as a group. For an individual project, this will include an assessment of how well you divided up your own time and how well you resolved problems as they came up.

Quality of Specification and Documentation: 40 points

Your readers will make an assessment of the quality of the documentation and of the code produced. This evaluation will include:

Final Presentation : 20 points

The presentation should be formal and professional. Allow 15 minutes for your presentation, with some time to answer questions. The presentation should give listeners an understanding of This is an important part of the evaluation of your group project, and this evaluation will be made by all of the CSci faculty in attendance - not simply your project supervisors. It is important to be well-prepared for this presentation. Total: 100 points

Project Evaluation

Your project will be read and evaluated by both of your supervising instructors. Each will assign grades independently. Others attending the final presentation will also assign a grade to your final presentation. At a meeting of computer science faculty all of the projects and grades will be discussed and a final grade assigned to your project at that time. During that meeting your project documents will be made available for general inspection.

Schedule

The following gives the schedule for project milestones. Although some of these dates can be modified (in advance!) in discussions with your project supervisors, it is important that a final set of dates be agreed to at the start of the project. 20% of your specification and documentation score (a total of 8 points) will depend on the timely delivery of the documents. In the absence of a modification to the following schedule (negotiated in advance with your supervisors), the following schedule will apply


Return to Group Project Home Page