Saint Louis University |
Dept. of Computer Science |
|
Computer Science 4961/4962
|
| Instructor: | Dr. Erin Chambers |
| Email: | echambe5 at our university domain |
| Office: | Ritter Hall 301 |
| Phone: | (314) 977-7002 |
| Office Hours: |
|
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:
Student Team
Each project is to be completed by a team of students, although
in some cases, that team may consist of a single student.
Instructor
The instructor-of-record for the course is responsible for the
administration of the course, scheduling of presentations, and
record keeping regarding grades.
Supervisor
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.
Client
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.
At the conclusion of the capstone project, the following course outcomes should be accomplished. Note that these will vary slightly if the project is a reseach project, as these outcomes are designed for the more traditional software design route.
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, January 27, 2017 .
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).
| Required Work | Deadline |
|---|---|
| Contract |
|
| Weekly reports | in class each Friday |
|
|
Thursday, March 9, 2017 |
| Midterm presentation |
|
|
|
Friday, May 5, 2017 |
| Final presentation |
|
| Team self-assessment | Thursday, May 11, 2017 |
Deliverables
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:
For more than you ever wanted to know about this process, read the IEEE overview of what such documents should contain. Other overviews and examples are available online. Keep in mind that these are relatively small scale projects, but we do expect you to be able to formally specify what your team will do in 5-10 pages, not including things like use cases or UI diagrams.
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.
Again, many different references exist online for how to write such a design document, and many of you have probably discussed it in classes such as software engineering. See the instructor if you have questions or would like to see examples.
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.
Note that these expectations may vary. For example, 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. See the course instructor if you have any questions about what your work should incorporate for your specific project.
Presentations
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.
Note that at a minimum, each member of the team is expected to discuss their specific contribution to the project, as well as challenges that came up for their component along the way. While no specific attire or presentation format is required, professional presentations generally do score better. At a minimum, teams must also have some sort of slide show that introduces and discusses their project in general before presenting any demos or technical details, as they should expect new members of the audience each time who may not be familiar with prior presentations. <\p>
Note also that every student is required to attend at least 2 other presentations, not including their own; this requirement is including in final presentations grades. Please contact the instructor if scheduling of the presentations makes this a hardship, and accommodations will be considered on a case by case basis (with good justifications).
Weekly Reports
Each team is responsible for submitting a brief progress report during
class each Friday of the semester. During the initial period,
when teams have not yet been formed, each individual should discuss
what progress has been made in researching potential projects
and teams; these first Friday meetings are a good place to form groups
or discuss ideas with other students looking for a team.
Once a contract is in place for a project, all
subsequent weekly reports will happen in class and should incorporate
details from each member of the team, each speaking for him or her self.
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.
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.
Team Self-Assessment
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 by the Thursday after
the final presentation each semester.
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