As a major part of the Senior Seminar, each student will lead the development of a major project. Seniors will conceive and design the project but it will be implemented with the assistance of their peers. This project provides one last chance to hone the many skills that a computer scientist must possess and will hopefully result in a tangible product to which you can point during interviews for graduate school or for positions in software development. The senior project represents the single largest component of your grade in this capstone course.
On the first day of classes, you should have narrowed your consideration to two or three project ideas. Ideal projects will perform a service of a somewhat novel nature. Formal proposals will be presented on Wed. of the first week; you may need to make changes based on these presentations. You must have an approved proposal by Friday of the first week of classes. The formal written proposal should be no more than two pages, single spaced (not counting any images you chose to include); your presentation on Wed. should be 4-5 minutes.
Your project may follow one of two patterns. You may choose a software development effort where the primary objective is to deliver a software artifact that accomplishes some purpose. Alternatively, you may choose a research project where the primary objective is to answer some particular question. In the latter case, the answer would typically (but not necessarily) rely on the implementation of a software artifact.
The proposal must contain three primary elements. It should first describe the objective in terms of the problem it will solve, the service it will provide, or the question it will answer. For any of those, you should motivate the effort with respect to why it is interesting, useful or worth doing. View this motivation component as a signifacnt matter; think of it as pitch to investors or a research proposal to a funding agency such as NSF. Answer the question, Why should the funding agent invest resources in your project? Second, you should describe the particular features that you will create or, in the case of a research-based effort, the particular work-units that together will let you answer the overall question you are addressing. For this element, you will want to be more technical than in the motivation; however, given a total time-length of five minutes, you cannot afford to go into too much detail. Finally, your proposal should also identify particular risks that could interfere with the success of the project. For each risk, describe mitigations that could be brought to bear.
If you are having trouble generating ideas for your project, the course instructor may provide project suggestions. However, this option is analogous to “buying a vowel”. We will serve as your customer and play a more significant role in design and scheduling; as a consequence, we will also expect a bit more from the final project.
After your project is approved and we have a more accurate count on the number of available assistants, you will scope your project and begin on the design. Scoping will take place in consultation with the instructors.
Your design will consist of interaction scenarios (use stories) and will identify modules/classes and their interfaces. Although you will be allowed to make changes to your design during development, your design must be complete with respect to your project proposal. The design is due on Fri. of the second week of class.
Once your design has been approved and teams have been established, you must draw up a schedule for the development. Your schedule must incorporate the four major milestones/presentations from the course schedule, but which functionality is completed at the respective milestones is up to you. Also, you are welcome (and encouraged) to include additional milestones. This has the benefit of early warning if you begin to get bogged down or off track.
You, with the assistance of your team, will develop the project over ten weeks (weeks 4-13). We have four major milestones during the development period: Wed. of weeks 7, 9, 11 and 13. Your project must be functional at all times (not just at milestones) subsequent to week 7. Although the project lead determines what functionality will be completed at each milestone, the projects will be graded, in part, by the progress from one milestone to the next. For example, a given project will be graded lower if it suddenly materializes between the 3rd and 4th milestones, as compared to the exact same project developed in relatively uniform increments over the four milestones.
Project leads choose (during design) the implementation language; you are required only to use free and platform independent languages. The same goes for the version control, bug tracking and unit testing tools that you select; you are required to use some version control and bug tracking tools but the choice of which is up to you. You will be required to demonstrate your unit testing methodology and it will be factored into the project grade.
In contrast to your proposal presentation, we expect your milestone presentations to focus on technical and project-management concerns. You should clearly describe the goals that you had set for the milestone in question and the extent to which you met, exceeded, or failed to meet each goal. You should present the highlights of your technical accomplishments for the time-period in question and you should expect (as we do) that you will demonstrate a running system. (This last requirement for a demonstration is somewhat relaxed if you are completing a research project.) Prepare and practice these presentations in advance and make sure they are within the appropriate time-bounds (usually 10-15 minutes without interruptions).
After the fourth milestone, you will have one week to address issues, fix bugs, complete missing functionality, etc. During the 15th week of classes, you will present your finished project at a public event .