|Instructor||David Ferry, Homepage|
|Course Web Site||http://cs.slu.edu/~dferry/courses/capstone/|
|Course meeting times||Monday from 4:10 - 5:00, Ritter Hall Rm. 120|
|Office hours||See my schedule|
The Capstone Project serves as a concluding achievement for graduating students, allowing them to apply knowledge that they have gained from the Computer Science curriculum toward a year-long project. Formally, the project is completed as part of a two-semester sequence of 2-credit courses: CSCI 4961 (Capstone Project I) and CSCI 4962 (Capstone Project II).
After successfully completing this course sequence, students will be able to:
Key roles in the capstone course are as follows:
Each project is to be completed by a team of students; in rare situations, that team may consist of a single student.
For most projects there will be a clearly identified "Client" who originally proposed the project or is a potential end user of the result; the client may or may not be a CS faculty member. The client typically serves as a primary point-of-contact in shaping the desired specification for the eventual product and may provide feedback on development prototypes.
Each project will have a "Supervisor" who is a CS faculty member that oversees the team's progress on the project. The Supervisor may or may not be the instructor-of-record for the course, and may be the same person as the Client, in cases where the Client is already a CS faculty member. The supervisor and instructor are jointly responsible for evaluating student teams.
The instructor-of-record for the course is responsible for the administration of the course, assignment of teams, scheduling of presentations, and record-keeping involving grades.
The Supervisor and the Instructor will work together in grading the performance of the teams. A non-CS Client may be consulted, but has no formal responsibilities in regard to evaluation.
At the onset of CSCI 4961, the instructor will circulate a list of potential projects to consider. These projects are often suggested by CS faculty members based on research endeavors or educational tools, are based on requests coming from members of the broader SLU community, or in some cases from external community groups. Students will also be afforded an opportunity to suggest project ideas for consideration. Projects should have an appropriate scope for a year-long sequence, having a richness in both aspects of design and use of technology. Past examples of project descriptions will be provided.
At the beginning of the second week, individual students will be asked to submit a ranked list of preferences for projects of interest, and preferences regarding the composition of student teams. The supervisors will make final determination of the teams and their assignments to projects, while taking into consideration the preferences submitted by students. Those assignments will be announced by the end of the second week.
During the third week, each student team must develop a formal Project Plan that outlines the scope of the project, and the timeline for major deliverables for both Capstone I and Capstone II. This plan must be approved and signed by both the Supervisor and Instructor no later than Friday, September 14, 2018 to be considered prompt.
Each project is unique, and teams may adopt one of a variety of project management styles. However, all teams must adhere to the following checkpoints and timeline (details of which follow).
|Project Plan (first draft)||
|Project Plan (final/signed version)||
|Weekly reports||each Monday|
||Friday, March 1, 2019|
||Friday, May 3, 2019|
|Team self-assessment||Friday, May 10, 2019|
Given the wide range of projects, there is no one-size-fits-all definition for the deliverables, but as part of the initial project plan, the students and Supervisor should outline four major stages of the project that are to be achieved by the four checkpoints in our timeline (middle of first semester, end of first semester, middle of second semester, end of second semester).
For teams following a traditional waterfall model, likely checkpoints are as follows:
Deliverable #2: Design Document
A writen document that describes a detailed design for achieving the formal requirements. A design document should include a description of the major components, their interfaces and how they interact to form the whole. Figures should be included for clarity, such as a UML diagram of the software design or an ER-diagram for a database. This document should also contain a discussion of any third-party technologies or software packages that will be used in meeting the project goals. Teams should demonstrate software prototypes showing that they have already evaluated and familiarized themselves with key technologies and design choices. Finally, this document must include a proposed time-line for the remainder of the project life cycle, making sure to include specific sub-goals for the development, implementation, and testing phases of the project.
Deliverable #3: Alpha Version
The alpha version of the project is a preliminary implementation that includes all major functionality of the final product, yet may lack some advanced features, have a less polished interface, and contain some known bugs.
Deliverable #4: Final Product
The final product must be submitted, including complete source code, documentation for deployment and usage, database schemas, analysis, and so on, as appropriate for the project.
For teams following an agile development process, the deliverables are more naturally going to be a series of working products with increasing refinement. For teams exploring research-driven questions, the deliverables might be papers that describe the work and results.
The teams will make four presentations during the two-semester sequence, typically just after a recent deliverable was submitted. Each presentation will be scheduled with 20 minutes for a formal presentation, followed by up to 10 minutes of questions from faculty members in the audience. Teams should prepare polished presentation materials and for most projects include a live demonstration of the current state of a product. Teams should test the presentation and demonstrations in the designated classroom well in advance of the scheduled presentation.
Copy of Slides from Michael Goldwasser's Presenting a Professional Professional Presentation
Here is a sample project presentation rubric.
Each team is responsible for presenting a brief progress report during most class periods. For Capstone I students, the first report will be on the third week of the semester; Capstone II teams will make their first report on the second week of the semester.
Each weekly presentation should detail what was accomplished during the week by each team member, what challenges were encountered, and a plan for activities in the upcoming week. Each team member must speak for herself or himself.
Please inform the instructor in advance if you need to miss the class meeting; up to two absences can be replaced with emailed weekly reports, but any absences beyond the first two will result in a grade penalty.
For teams comprised of two or more students, each individual must complete and submit a Team Self-Assessment Form, detailing his or her perception of the contributions of each team member. This assessment is due to the instructor after the final presentation each semester.
All teams will be required to use the department git repositories for all project artifacts (e.g., all deliverables, source codes, presentation materials). Both the instructor and supervisor will be granted access to the repository from the beginning of the project. An analysis of contributions to the repository may be used as additional evidence of individuals' participation.
Each semester of the capstone project is graded based upon the performance during that semester. The evaluation of students' artifacts and presentations will be made by a combination of the Instructor and project Supervisor. The overall grade will be weighted as follows:
Letter grades will then be assigned based on the following formula.