| Assignment | Due Date | Weight |
|---|---|---|
| Prospectus | September 11 | 5% |
| Bibliography | September 16 | 10% |
| Design Specification and Presentation | September 25 | 10% |
| License Agreement | October 9 | 5% |
| Users' Manual & Overall Product Usability | November 11 | 15% |
| Product Implementation and Documentation | November 18 | 20% |
| Final Oral Presentation | December 2 or 4 | 10% |
| Sponsor Evaluation | December 4 | 10% |
| Final Report & Overall Project Quality | December 6 | 15% |
| Final Interview and Exit Survey | December 9-13 |
The purpose of this requirement is to encourage you to determine your project topic as quickly as possible and to undertake preliminary thinking and planning about the work that your project will involve. Before writing your prospectus, you should, of course, have at least one brief preliminary discussion of your project with your sponsor. Write a very brief description, abstract, or overview of your project topic. It may be difficult to include very much detail at this point, but try to be as specific as it is possible and reasonable to be.
Describe what your project is concerned with, what you will need to do to complete the project, and what the end result or product of your project will be.
Type your prospectus in a double-spaced format. The maximum length is two pages. Also include the following items of information: your name, email address, and a telephone number at which you can be reached; a proposed title for your project; the name, organization, telephone number, and email address of your sponsor; a signed Honor Code statement (which should be attached as a separate sheet).
Your prospectus must be approved by your instructor before you begin the actual work involved in your project. Your project has no official standing or status as a means for satisfying the requirements for CSCI 487 until your prospectus has been approved by the course instructor. It is a good idea to have your sponsor also read and approve the prospectus. The more interaction you have with your sponsor, the less chance there is of having a misunderstanding of the purpose, scope, or usage of the project.
Submit your prospectus to your instructor on the assigned date. The instructor will review your prospectus as quickly as possible in order to suggest changes that may be necessary prior to approval. Your prospectus will also be reviewed by your sponsor in a manner to be discussed in class. Normally the instructor will give you an idea of the relative difficulty of your project. All projects are different and they have varying levels of difficulty. If you choose a project that is less difficult, the standards for interface, robustness, documentation, etc. will be higher. If you choose a difficult project, some flexibility may be given with respect to completeness, interface or robustness.
The goal is to choose a project that is interesting and challenging. Often the senior project is an extremely valuable experience for students, and is sometimes used as an important project to entice potential employers. Sometimes the sponser will agree to be a reference for a student who is looking for a job. Some sponsors have even hired students who have done exceptional projects.
Repeat: the maximum length of the Prospectus is two printed, double-spaced pages.
There are two purposes for this requirement:
Prepare a list of sources that are relevant to your project. This bibliography should include all sources that you have consulted, read, reviewed, and/or skimmed in carrying out the project. Early in the semester (when this assignment is due), include items that you plan to read or review later, even if you have not had time to consult them in detail yet. (By the time you prepare your final report, changes in the bibliography can be made.)
You should include obvious sources, such as hardware and software manuals and reference books relevant to your project. However, this assignment also requires you to undertake some library and online research to find books, journal and conference articles, and reports that are relevant to the topic of your project. A good place to start is the ACM Digital Library.
Entries in your bibliography should be presented in a format consistent with the bibliographic style used in ACM publications or presented in Kate L. Turabian's A Manual For Writers of Term Papers, Theses, and Dissertations. Copies of this book can be purchased in the bookstore or found in the library. It is recommended that you organize your bibliography in sections that group different types of items (for example, manuals; books; journal articles; Web pages) together. Within each category, the entries should be arranged in alphabetical order by the first author's last name. Be especially careful with WWW references. You should minimally include the URL and either the last modified date, or the date you accessed the page. The dynamic nature of the Web makes referencing web pages difficult.
Each entry in your bibliography should include a brief annotation, consisting of approximately 50 words, written by you, describing what that item is and why it is relevant to your project.
There is no minimum or maximum number of items that must be included in your bibliography. Your bibliography should demonstrate that you have done serious research to determine relevant sources. While there is no minimum number of entries it is expected that this document will be several pages long and will be the result of five to ten hours of research in the library or online.
Your bibliography should be prepared with a word processor and printed. Include your name and project title as part of the heading for the bibliography. Entries and annotations should be single-spaced, with one blank line between each entry. Attach a signed copy of the Honor Code statement to the bibliography.
The purpose of this requirement is to encourage you to approach your project in an orderly, organized, top-down manner by defining overall project requirements and implementation strategies at the time that you are preparing to begin the actual programming work.
Write a narrative document that describes your project in more detail than was required (or perhaps possible) at the time that the prospectus was written. Organization and format of this document is up to you, but you should include discussion of the following.
Note: The above assumes that your project consists primarily of designing and implementing a software system. If your project has a different nature, then you may want to discuss the content of your design specification with your instructor.
The design specification document should be printed double-spaced. Include your name and project title as part of the heading for the document.
The length of this document is open, but it should certainly be longer than the two-page prospectus. Perhaps five typed, double-spaced pages would be a reasonable length.
Attach a signed copy of the Honor Code statement to your design specification document.
Oral Presentation. On the day that the design specification is due, you should be prepared to present your design orally to your instructor and classmates. The presentation should take no more than 10 minutes. Use audiovisual aids as appropriate.
The purpose of this presentation is to help you discover any problems with your design and to give you practice in presenting technical material orally. (See the section on the final oral presentation for more information about presentations in this class.)
CSCI 487 is not a law school course, and there are (usually) no lawyers involved in the projects associated with this course. The purpose of this requirement, however, is to provide you with some informal experience in preparing a license agreement that defines the relationships between, and expectations of, you and your sponsor.
The license agreement essentially defines an academic "contract" between you and your sponsor. It should define the items that you will provide to the sponsor and the schedule for delivering them. It should also define what the sponsor will provide to you (e.g., regular meetings, access to software or hardware). You may want to define any on-going responsibility that you will have to maintain the project's materials. (In most cases, you will not want to promise any support after the completion of the project.)
An issue that may need to be resolved with your sponsor is what rights you and the sponsor (or his organization) have to the project materials (program executables, source code, documents) after delivery. However, be aware that raising this issue will sometimes make it difficult to formulate a license that both you and your sponsor can agree upon--especially if your sponsor is in a private business.
Here is your instructor's opinion on this matter. In general, since your sponsor did go to some trouble to sponsor your work, he/she (or his/her organization) should have the right to use, modify, and extend the project software and materials after delivery. The sponsor should also have the right to protect any confidential or proprietary information or components that went into your project. However, since you were not paid to carry out the project, you may also want to retain the right to use it for other purposes, including development of a derivative product. You and the sponsor might want to consider allowing the software to be freely distributed under an "open source" arrangement (see http://www.debian.org/social_contract.html) or the GNU General Public License ).
The usual restrictions concerning plagiarism do not apply to this assignment. Please review the provided sample license agreements, and prepare a similar document concerning your project. Your design specification document has already been written, so you should have no trouble in preparing a license agreement, modeled after one or more of the samples, which covers the specific characteristics of your project.
You will, of course, need to type your license agreement in a format similar to the provided samples. It is your responsibility to arrange for you and your sponsor to sign the license agreement before turning it in to the instructor. This should provide you with one last opportunity to make sure that you and your sponsor understand clearly what expectations are associated with your project. Most sponsors will expect the student to explain clearly and distinctly what the various features of your license agreement mean; some sponsors may in fact refuse to sign the agreement until you clear up any ambiguities.
Attach a modified version of the Honor Code statement to your license agreement document that you submit to the instructor. (This modified statement states that you have done, by yourself, the work of preparing the document although it is modeled after one or more of the samples.) The Honor Code Statement should be on a separate sheet of paper.
Periodic status reporting is a requirement on most computer-related projects in business and industry. This helps keep a project on track and management aware of the progress being made.
During the middle weeks of the semester you will be working intensely on the implementation of your project. The class will meet every week or two for status reports. At the times indicated on the schedule, you are expected to provide brief written reports (one paragraph to one page) giving the status of your work and the progress you have made since the previous report. Relate your status to the schedule you set up in the design specification. At all meetings of the class, you should also be prepared to orally discuss the status of your work to that point.
The purpose of this requirement is to encourage you to provide your sponsor and other users with clear and complete instructions on how to install, use, and administer your project's product. This section assumes that your product consists primarily of software. If your project is of a different nature, then you will need to modify the content and structure of the users' manual appropriately. However, keep in mind that the purpose of this assignment is to explain how to use the product effectively.
The user-level documentation will likely be examined by more individuals from more diverse backgrounds than the other project documents. Thus try to identify the possible user communities for your product and organize the documentation appropriately for those users. Write clearly. Avoid unnecessary jargon. Define any specialized terms you use. State any assumptions you make. Provide the documentation in a useful format. In general, you should provide the documentation in a format suitable for online display (e.g., in an HTML format) and as well as in printed form.
The users' manual should explain how to configure and install your project's product on a computer system. As appropriate, describe how to compile and link the software. Be sure to document any assumptions about and dependencies on other software packages, libraries, files, specialized hardware components, etc. Explain how to deploy your project's files (executables, libraries, configuration files, etc.) on a user's computer system. Describe how to use any installation and configuration scripts (e.g., batch files) you provide as a part of your system. Similarly, you might need to describe how to uninstall the software from a system.
The users' manual should also explain how to administer your project's product once installed. Explain what the administrator of the product (or of the computer system that hosts it) must do to keep the product operating smoothly and reliably. If you provided an administrator or "superuser" mode, then describe the user interface and functionality of the commands associated with that mode. For example, how are users enabled and disabled from using the product? Once installed, what configuration changes (if any) are supported? What files (if any) should be backed-up regularly? And so forth.
Of course, the most important audience of the users' manual is probably the group of ordinary users. Be sure to describe the user interface structure and functionality clearly. Keep in mind that some users of your product may be inexperienced or unsophisticated computer users or may not have the opportunity to be trained on use of your product. Documentation for these novice users may need to be somewhat tutorial in nature. Other users may be more experienced and sophisticated, but may use your product infrequently. These more sophisticated users need to refer to the documentation to answer specific "how to" questions quickly.
You may also want to include a section in the user documentation that discusses how to enhance and extend the product and suggests possible enhancements.
The instructor will, on the day that she evaluates your project, use your users' manual to run your program. She will judge the viability of your project by how much difficulty she has using your program with your set of instructions. Remember she will make no assumptions about the machine or the program. She will do just what this document tells her to do.
Prepare a printed copy of your users' manual for submission to your instructor and attach a signed copy of the Honor Code statement.
The primary purpose of this requirement is to encourage you to produce high quality, well-structured, well-documented source code.
As appropriate, you are also encouraged to produce supplemental documentation of your product's structure and functionality. For example, it is often useful to provide high-level architectural descriptions as annotated drawings. Consider using a standard notation like the UML (Unified Modeling Language).
Internal program documentation should include:
Internal program documentation can be presented in any appropriate format and style. Your goal should be to prepare a program listing that could be read, and understood, as easily as possible by some future consultant who might need to work on it.
As appropriate, take advantage of tools that may be readily available in a development environment. For example, Java programs can be documented using Javadoc annotations. The Javadoc tool can then be employed to generate well-formatted HTML documentation that may be useful for reference.
The following are relevant criteria used in judging the quality of your code and documentation:
Attach a signed copy of the Honor Code statement to program listing you submit. This should be on a separate sheet.
Sometimes the "source code" files for a project may be huge, especially when part or all are generated by a tool. In this case, it is better to provide the entire source code by email or on a CD or DVD, along with printed documentation and a table of contents.
The purpose of this assignment is to encourage you to be able to make short oral presentations in professional situations.
Toward the end of the term, you will be assigned a time slot for the presentation of your project, if your instructor feels your project is or will be complete by the day of the presentation. Your presentation should be no longer than 15 to 20 minutes. Practice your presentation so that you are sure that it will fit into the 15-to-20-minute limitation.
Each presentation will be followed by a brief question and answer session.
In determining your grade for the oral presentation, the relevant factors include:
The presentations are open to the public. In general, your audience will include the other Senior Project students, your instructor, other faculty members and students from the Department, your sponsor (whom you should personally invite), and any other interested persons. The audience members will be asked to fill out an evaluation form for your presentation.
All students are expected to attend all of the presentations. Normally the presentations will begin at 4:00 on Monday and Wednesday of the last week of class. They will be scheduled every half hour. If there are too many students, some may be scheduled on Tuesday or Thursday evening, or presentations may begin at 3:00. Any student who cannot attend a presenation should obtain prior approval of the instructor.
In consultation with your instructor, the department system administrator, and fellow students, you are responsible for making appropriate arrangements for and setting up any equipment and software you need for your presentation.
The purpose of this requirement is to provide your sponsor with an opportunity to evaluate your performance in pursuing your project. Remember that your sponsor is your client or customer. Under the terms of the license agreement, you are to carry out the project and deliver the specified result to your sponsor before the end of classes for the semester.
It is the responsibility of the student to ensure the instructor has complete and correct contact information for your sponsor so he or she can be contacted by the instructor to obtain the evaluation.
You should mention to your sponsor that your instructor will contact him or her to evaluate your performance in the course.
The purpose of this requirement is to provide an opportunity for you to bring all aspects of your project together into one complete, final document. Be sure to include corrections to each document, as indicated by the instructore. Organize your materials in an attractive format and bind them in the following order:
Materials that were submitted in double-spaced format earlier should, in general, be reformatted into a single-spaced format (which is usually more attractive and uses less paper). You should bind the materials in a soft-cover binding that is only as thick as needed. (Do not put your final report in a 2-inch three-ring binder if your materials are only 0.5 inch thick!) Tab separator pages between the sections are helpful.
You are reminded that the Department of Computer and Information Science has available to ALL of its students the hardware and software that allows all documents to be completed in a very professional manner. As Seniors you are expected to use this equipment or similar equipment for all final documents. In particular, the department owns a binding maching that the department secretary can show you how to use.
Item 4, the report, is the only item that is really new about this assignment. This should be a narrative document that reports your experiences in carrying out your project. In writing this report, consider such questions as: How well were the project's goals realized? What "went right" and what "went wrong" in your design and implementation or in your interactions with your sponsor? What would you do differently if you were to do the project again? What did you learn from the project? What are possible extensions, enhancements, or alternative approaches to the project that can be considered? And so forth.
You are also required to deliver your project materials to your sponsor as specified in the License Agreement.
UP to 487 root document?
Copyright © 2013, H. Conrad Cunningham
Last modified: Mon, 26 Aug 2013