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 industry. 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 in class on Wednesday 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 prepared presentation on Wednesday should be between four and five 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 will enable you to 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 four to 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 you intend to apply. This section should demonstrate that you've thought about some of the things that might go wrong and what you can do about them. As a heuristic guideline for planning your presentation, you might plan to spend 90 seconds on the motivation, two minutes on the features or work units, and one minute on the risks.
If you are having trouble generating ideas for your project, talk to the course instructor sooner rather than later. The schedule is tight and has little allowance for spinning of wheels.
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 the design. Scoping and design work together in the process of conscribing how many of the features described in your proposal can be realistically implemented in the available time. Thus, a detailed articulation of the functionality is necessary for determining what can and cannot be accomplished.
Scoping will take place in consultation with the instructors. As a useful guideline, you should plan for at least ten hours per week that you will be allocating to your project (in addition to the one or two hours per week for other Senior Seminar assignments). If an another student will be assisting you with your project, you should anticipate four hours per week from him or her (based on a compression of their work into ten weeks). Use these guidelines when scoping your project
In contrast to your proposal that emphasized motivation and touched only lightly on technical matters, your design should be all about the technical. We do not prescribe a spcefic format that your design must follow, but use the following guiding principle to evaluate your deliverable. You must provide sufficient detail in terms of features, functionality, flow and user experience such that someone else could pick up your design and produce an implementation of it. As such, you need to describe the interaction scenarios (use stories) that you want to support. You might choose to 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. You should add your design to the senior project page of your portfolio.
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. However, which subsets of functionality are completed at which 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. Spend time thinking about how you want to organize your schedule. You will be repeately revisiting your schedule and the corresponding partitioning of features as you present progress updates. During such updates, you will be expected to clearly identify your goals for the given deliverable date and how well you completed each.
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 .