Department of Mathematics and Computer Science
January, 2004
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. Both readers should receive copies of all scheduled documents at the time they are due. In addition, the course coordinator (if not already a first or second reader) should receive a copy.
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. The schedule for all documents not explicitly scheduled below should be included in the Requirements Document.
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. This document will be due by the end of the second week of the term (January 30, 2004).
Each group is required to produce a requirements document and a requirements analysis document. Requirements documents should include a clear statement of the problem with a clear description of functional and non-functional user and system requirements. The use of illustrative diagrams (using Rational Rose and Visio) is encouraged.
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.
This document should specify in detail the hardware and software resources to be used by the project, and where the resources will be obtained (generally in the ACL or in T124, but your projects may use resources elsewhere). In addition to submitting this to your first and second readers, this document (together with subsequent updates to it) should go also to Paul Monaghan who needs to know what demands may be made on the lab. This is true even if you expect to do your work somewhere else - it is not uncommon for plans to use hardware and software somewhere else to fall through creating sudden last-minute demands on the Thompson Hall labs. So - even if your project will be using resources somewhere else on campus or even off-campus, this new document requirement asks you to keep Paul and your readers informed on the resources you plan to use and where you plan to find them.
These three documents may be combined into one document if desired. The three documents will be due Friday, February 13, unless other arrangements have been made with the project's reader and the course supervisor.
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.
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.
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.
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.
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).
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.
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, scripts, XML/HTML, etc.) should be included as appendices. We will need three-four copies - two for your readers, one for the course supervisor (if that person is not already one of your readers), and (optionally) 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.
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.
Your project will be evaluated against the following criteria (These criteria are adopted from those used in software engineering projects at the University of Wales, Aberystwyth)
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.
Your readers will make an assessment of the quality of the documentation and of the code produced. This evaluation will include:
Points will be deducted for tardy submission of documents.
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
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.
The following gives the schedule for project milestones. Although some of these dates can be set or 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. For projects that require additional documents, delivery dates should be set with your readers at the start of the term. All scheduled documents should be submitted to both of your readers. 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
Normally, projects should require only resources available to students at the University of Puget Sound. The Department does not have a budget for additional hardware and software to support projects. Students considering a project requiring additional resources should consider applying to the University Enrichment Committee for undergraduate research funds. Please note that applications for undergraduate research funds allocated through the University Enrichment Committee must be prepared well ahead of the time the funds would be needed, and that UEC funds for undergraduate research are granted competitively. A detailed list of all hardware and software resources expected should be filed with your readers and with Mark Young, who should also be kept up-to-date on any changes to this list.