Computer Science 4961/4962
If you wish, you may download a printable version of the syllabus, containing the same information that is on this web page.
|Instructor:||Dr. Michael Goldwasser|
|Email:||goldwamh at our university domain|
|Office:||Ritter Hall 355|
The Capstone Project serves a 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).
Key roles in the capstone course are as follows:
Each project is to be completed by a team of students, although in some cases, that team may consist of a single student.
The instructor-of-record for the course is responsible for the administration of the course, scheduling of presentations, and record keeping regarding grades.
Each project will have a "Supervisor" who is a CS faculty member who will oversee the team on the project, and can be a sounding board on technical issues. The Supervisor may or may not be the Instructor-of-record for the course.
For some projects, there will be a clearly identified "Client" who originally proposed the project or is a potential end user of the result. The client might serve as a primary point-of-contact in shaping the desired specification for an end product and to provide feedback on early prototypes.
The Supervisor and the Instructor will work together in grading the performance of the teams. The Client has no formal responsibilities in regard to evaluation.
During the opening weeks of CSCI 4961, students are responsible for working with the instructor, potential supervising faculty, and peer students in order to build teams, explore project ideas, and develop a concrete plan for the year, culuminating in a formal contract (see below).
Typically, 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 non-profit groups. Student teams are also welcome to suggest their own projects for approval. The goal is to pursue projects that have an appropriate scope for a year-long sequence, having a richness in both design aspects and use of technology. For the sake of example, we provide this list of some past project descriptions.
At the conclusion of the initial period, teams must sign a contract, together with the Supervisor and Instructor, providing a high-level project description and detailing the requirements for successful completion, and key checkpoints during the process. This year, the contract must be signed by Friday, September 11, 2015 .
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).
|Weekly reports||submitted each Friday|
||Friday, October 9, 2015|
||Friday, December 4, 2015|
|Team self-assessment||Tuesday, December 8, 2015|
Given the wide range of projects, there is no one-size-fits-all definition for the deliverables, but as part of the initial contract, 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 that they have already evaluated and familiarized themselves with any such technologies. 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 also make sure to test the presentation and demonstrations in the Linux lab, well in advance of their scheduled presentation.
Each team is responsible for submitting a brief progress report by the end of each Friday of the semester. During the initial period, when teams have not yet been formed, each individual should email a report to the Instructor letting him or her know about what progress has been made in researching potential projects and teams. Once a contract is in place for a project, all subsequent weekly reports should be submitted to the team repository (details below), and accessible to both the Instructor and the project Supervisor.
A report should indicate what was accomplished during the week by each team member, what challenges were encountered, and a plan for activities in the upcoming week.
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.
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.
All teams will be required to use git repositories on turing for all project artifacts (e.g., weekly reports, all deliverables, source codes, presentation materials). More details about the process will be forthcoming.
Academic integrity is honesty, truthful and responsible conduct in all academic endeavors. The mission of Saint Louis University is "the pursuit of truth for the greater glory of God and for the service of humanity." Accordingly, all acts of falsehood demean and compromise the corporate endeavors of teaching, research, health care, and community service via which SLU embodies its mission. The University strives to prepare students for lives of personal and professional integrity, and therefore regards all breaches of academic integrity as matters of serious concern.
The governing University-level Academic Integrity Policy can be accessed on the Provost's Office website. A more detailed policy statement is given by the College of Arts & Science, also applying to this course.
In recognition that people learn in a variety of ways and that learning is influenced by multiple factors (e.g., prior experience, study skills, learning disability), resources to support student success are available on campus. Students who think they might benefit from these resources can find out more about:
Students with a documented disability who wish to request
academic accommodations are encouraged to contact
Disability Services at