CSCI 4243W - Senior Design

Posted on July 24, 2018 by Gabriel Parmer and Rahul Simha

Course Info

Instructors Contact info:

Mentors:

Instructors:

Chris Toombs
Elyse Nicolas

Fall 2018 Class Time/Location:

Project Updates and Sprint Planning Meetings with Mentors: Tuesdays 2:00-3:15PM and 3:30-4:45, TOMP 402
Lectures, Presentations, and Demos with Instructors: Wednesdays 6:10-8:40PM, TOMP 201

Office Hours:

For general class questions, use Piazza.
Otherwise, email for an appointment.

Textbook

There is no official textbook. Readings will be recommended where appropriate.

Course Overview

Learning outcomes:

Learn key elements in the development of a significant year-long computer science project: planning, specification, design, analysis, and implementation.
Apply concepts from software engineering to the project: requirements, specification, reuse, documentation, verification and validation, testing, configuration management
Learn to write about and practice presentations about important aspects of the project: the case for launching the project, status reports, design, and implementation plan.
Demonstrate a working project.
Demonstrate an understanding of how knowledge and skill in computer science courses played a role in the project.
Demonstrate an understanding of how continuing education can contribute to career development.
Explore issues related to local and global impact of computing, as well as social impact issues.

Direct Instruction and Independent Learning

Each semester, you’re expected to spend at least:

55 hours in class and lab for direct instruction, and
150 hours out of class working on your project and class assignments.

Booting up

You should have already received an email with a survey about project topics and teams. If you haven’t, contact us immediately. When discussing and thinking about projects, please keep in mind the project criteria.

Piazza. We will be using Piazza as an online class forum. Don’t hesitate to ask general questions here, but please do not include code (see Academic Honesty below).

Trello and Github. We will be using Trello and Github for project and code management. Please carefully read how we will use them in this class. It is your responsibility to abide by the conventions spelled out here for their use.

Please see the email that has gone out to all SD students in August and fill out the form therein.

Project Webpage

You must have a webpage for your project. We are using Github pages as detailed on our page about how to use Github for SD. You must have your webpage up and running by the first Writing Assignment deadline to properly submit that assignment.

Schedule

Week	Tuesday	Wednesday	Sunday Deadlines
Aug 26th	Intro to SD	Project Discussion/Planning
Sept 2nd	Project Update	Design I
Sept 8th	Presentation Workshop (Saturday), SPM
Sept 9th	Project Update	Design II	Writing I
Sept 16th	Project Update	Developer Tools	Group Feedback (Opt), Equipment Requests
Sept 23rd	Sprint Planning Meeting	Design III
Sept 30th	Project Update	Presentation I	Writing II
Oct 7th	Fall Break	Human-Computer Design I
Oct 14th	Boot-Camp Demo	Presentation II	Group Feedback (Optional)
Oct 21st	Sprint Planning Meeting	Human-Computer Design II	Writing III
Oct 28th	Project Update	Demo Review	Cover Letter and CV
Nov 4th	Project Update	Mock Interviews
Nov 11th	Project Update	Presentation III	Group Feedback (Opt), Interface Design Doc
Nov 18th	Project Update	Thanksgiving Break
Nov 25th	Sprint Planning Meeting	Design Review	Writing IV
Dec 2nd	40% Demos	40% Demo	Final Design Document
Winter Sprint!	…lotsa progress…	…to be had!	😊
Jan 13th	SPM	Coding++
Jan 20th	70% Demo	Applying HCI	Group Feedback (Opt)
Jan 27th	Project Update	HCI Huddle
Feb 3rd	Project Update	Mock 100% demo
Feb 10th	SPM	Final Presentation v1
Feb 17th	Project Update	Money Management
Feb 24th	85% Demo	85% Demo
Mar 3rd	Project Update	Final Presentation v2
Mar 10th	Hacking Intensive
Mar 17th	SPM	Senior Focus Group
Mar 24th	Project Update	Final Presentation Practice
Mar 31st	Project Update	Life after College
April 7th	N/A	Final Presentation Practice
April 14th	N/A	TBD
April 21st	Final Presentations	Final Presentations
May 7th		Final Package Due
May 17th		Senior Design showcase @ 11:30-2pm

Submit all deadlines in your shared drive with the exception of Group Feedback. Submit Group Feedback by email to your mentor (see “Group Feedback” below).

Please note that SD Sprints span fall break, thanksgiving break, and winter break, and that demos and presentations are due soon after many of these breaks. Correspondingly, you are expected to make consistent progress on senior design, and if you don’t meet these expectations without working over these breaks you must expect to make progress during them.

Project updates are done for your mentor. You must come prepared. This means ensuring that Trello is updated with your current progress. You should walk your advisor though your progress through your cards. If your cards are not updated and you aren’t ready to present, you’ll automatically get a 0% on progress for the previous period.

Written Assignments

SD’s writing assignments help you practice communicating your idea and putting it into a broader context. Each writing assignment has the deadline specified in the schedule.

Presentation Assignments

See the bottom portion of the webpage on writing and presentations for information on the presentations.

Assignment submission

Written assignments. Written assignments will be submitted (unless otherwise noted) as follows:

Prof. Parmer should have made a shared folder on google drive that you will use to submit all of your written assignments. It should already be populated with empty drafts of each assignment. Please populate the documents in that folder, and upload a pdf with the same name (but a pdf extension) for submission. If the pdf exists, we will grade it.
Post the pdfs of your documents on your project’s Github webpage.

You must post your written assignments in both places by the deadline.

Presentations. Please submit your presentations by linking them on your project’s webpage in pdf format. The main deliverable is, of course, the actual presentation.

Demos and code. Your github repos are your “living submissions”. We will look through your github commit activity to gauge constant progress. On Demo days, please use a git tag to annotate the commit you’re using for the demo. Name the tag demo-X where X is the demo number. Come to class prepared with a polished demo that accurately depicts your progress.

Sprint planning meeting. Before each sprint planning meeting, you should make sure that your “Backlog” list in Trello is populated, labeled, and assigned to the proper team member. Please leave any task that remains from the previous sprint in the “TODO this Sprint” list, in that list. In the meeting, you’ll move tasks from the “Backlog” into the “TODO this Sprint” with your SD Mentor. Please ensure that you use Trello as spelled out for this class. As detailed in that webpage in “Trello and Sprint Planning Meetings (SPM)” you must prepare for the “Sprint Planning Meeting” with your SD mentor, and must structure your cards in the specified way.

If the tasks that you’ve allocated for a sprint are deemed by your SD Mentor to not represent sufficient progress, then you must schedule a meeting with your SD Mentor the same week as the “Sprint Planning Meeting”, and go to that meeting with an expanded set of tasks. Similarly, if you’re discussion goes over the amount of time allocated to your group, your SD Mentor might require you schedule an meeting the same week to finish planning.

Academic honesty. You must handle your Trello tasks, github commits, and demos with integrity. See the Academic Honesty section for more information about how to lose a lot of credit quickly by not handling these with honesty.

Final Package

Please submit the following by noon, Tuesday May 7 as a tarball or zipfile in your group’s google drive and via email to your mentor (a replica should be in your team’s github account):

Code.

The most recent working version of your project’s code.
A README file that explains how to install all libraries needed, what paths need to be set up etc to get your project running.
A simple test program that can be run at the command-line that will run only if everything is correctly installed.

Equipment (if applicable).

If your project involved equipment bought by the Department, please return the equipment before noon on Tuesday, May 7.

Screencast.

Create an 8-minute screencast using the slides in your final presentation where you talk as you go from slide to slide. Think of this as a record of your final presentation that anyone can view.

Poster.

Create a standard-sized poster (typically 9 slides) of your project. Create a PDF but await instructions about printing and making the poster itself.

Project webpage.

Create a single page for yourself and your project with the following elements:
A clear picture of yourself.
A short (one paragraph) biosketch that says a little about you, your interests, dreams etc.
Your screencast of your final presentation.
Links to the following:
- The writing assignments from Fall.
- Your poster.
- Instructions for follow-on projects. Write a detailed set of instructions for the next group of SD students who will build on your project:
- An explanation of your project (2 paragraphs).
- How to download and get the project working.
- What tools and libraries are needed.
- What works, what doesn’t, what to be aware of (pitfalls, issues).
- Ideas for next steps.
- Note: some juniors have already shown interest. We may ask some of them to try out your instructions. Please make sure they work!

Group Dynamics

It can be difficult working in a team, but it is essential in SD that all group members are productive and work together toward the project’s goals. Here we discuss what to do if the group dynamics break down at all.

Toxic group dynamics. A collegial environment must be maintained at all points during SD. Disrespect for each other, harassment of any form, or any other form of inappropriate behavior will not be tolerated in SD. Your demeanor in your group can negatively impact your grade, and will be passed to university-level disciplinary action where warranted. If you have concerns about your teammates, or yourself not nurturing a collegial environment, please send an email immediately to your SD Mentor with title “SD: Group Problem”.

Group Feedback. Every month, you can optionally submit Group Feedback to your SD Mentor. These reviews are an opportunity to raise any concerns you have with your group. If you do submit one, please include the names of all team members. Suggested topics you likely want to include in your review:

How you are performing within the group.
How others in your are performing in your perception.
Any evidence (i.e. commit history) to support your claims.

Your SD Mentor will use your review to help ensure that teams are functioning productively. We will not share the contents of your review with your other members unless you want us to. Most likely, we will use this information to facilitate a discussion between group members. If group dynamics break down, it will impact assigned grades.

Though we include explicit deadlines when you can submit group feedback, to remind people to use this mechanism, you should feel free to send group feedback anytime you feel it is necessary. If you have not sent us group feedback, and complain at a later date about group issues that prevent you from making progress, we will not be receptive. Thus, it is necessary that you don’t procrastinate, so that you notice any problems and can raise them earlier than later, and that you are active about reporting negative group dynamics.

Submission of Group Feedback. Please email your SD Mentor using the title “SD: Group Feedback”. Include your group feedback in the body of the email.

Late work policy

Writing Assignment Late policy: late writing assignments will yield 50% credit until the next writing assignment is due at which point, it will not be accepted.
Submission of all writing assignments must follow the submission rules above. All reports, presentations and such will be submitted via your project website and via google drive as a document and as a pdf (which we will use for grading).
Presentations and Demos cannot be submitted late for credit as they are required in-class.
The submission time will be determined by the upload time of the pdf on google drive.
If you’re seeking an extension because you’ve been ill and have a letter from a doctor, please see us about it. Please remember that many deadlines for this class are known far in advance, so being sick for (for example) 5 days might not be reasonable justification for an extension.

Grading

Your grade in this class will be determined by

Setting monthly sprint goals that are realistic and will yield a completed project while meeting those goals. You will determine these tasks during the “Sprint Planning Meeting” with your SD Mentor. Your grade will be dependent on 1. you creating an appropriate “Backlog” before the “Sprint Planning Meeting”, 2. the tasks for a given sprint making appropriate progress toward your final goals, and 3. your completion of tasks over the past sprint. You will receive a grade each month. If you do not finish all of your tasks in a given month, your grade will reflect that. Unfinished tasks will lower your score by a corresponding amount. You should know during the monthly “Sprint Planning Meeting” what your grade is for the past month. Since software predictions are difficult, we will ignore your lowest month’s score.
Your demos must reflect the state up until that point of your Trello board. If they demonstrate progress less than what has been demonstrated on Trello, your grade will be correspondingly adjusted downwards.
Making steady commits and pull requests to your repository. Your grade can be negatively impacted by a lack of steady commits and progress.
Your writing assignment grades. Each writing assignment is graded separately, and contribute to your final grade. These will be graded as a group, unless team dynamics issues have been raised before submission.
Your presentations must show progress over the year, and must address the feedback provided to you after each presentation.
The final product.
Participation in all class activities. This involves coming to classes, and being active in them.

Grade breakdown.

Fall ’18:

Presentations: 17%
Writing assignments and Design homeworks: 17%
Grades from Sprint Progress Meetings, Demos, and Github commit/pull request progress: 30%
Final project: 30%
Participation and Initiative: 6%

Spring ’19:

Presentations: 30%
Grades from Sprint Progress Meetings, Demos, and Github commit/pull request progress: 25%
Final project: 35%
Participation and Initiative: 10%

Fall semester grade. At the end of the Fall semester, you will be given a grade based on

how ambitious your monthly planned sprints are and if they show the initiative necessary to complete your project,
how well you meet all of your sprint goals, and
how well your demos represent that progress.

Together, these factors determine how far along your project is relative to where it needs to be at completion.

Your Spring semester grade is based on the same factors, but also on if you show the initiative to polish push your project to be the best it can be, and on the final quality of your project.

Individual grades. Even though you will be working in a group, the majority of your grade will be derived from your individual progress. You must submit group reports, and any continual problems with your team members will also impact your grade. See the discussion of “Group Dynamics” above.

Falling Behind in SD

If we determine that a group is not making sufficient progress toward the goals of their project, we will require all group members to come in and work on their project in a supervised setting. This is meant to provide bursts of activity to get the group back on track. It is each group’s responsibility to put in the work required to create a successful project.

Academic Integrity policy

In this course, your activity in your github repo will impact your grade. Because of this, all of your commits to your repo should be in “good faith”. That is, you should not submit changes that do not represent changes of substance and progress to your repo. “Faking” activity will be handled with penalties to your grade. Violating this will result in losing all credit related to the window of time the code was committed in (including valid commits).
Similarly, you should handle your tasks on Trello with integrity. Only mark a task as completed when its acceptance criteria are actually completed. Do not move a task out of your “TODO this Sprint” list unless you’re moving it into a “completed” list for the appropriate month. Please do note that Trello does track all movements and activity. Violating this will result in losing all credit for the offending sprint(s) (including tasks completed honestly). A conversation you don’t want to have later in the SD process is why some task isn’t complete even though Trello states that it is. This will have negative repercussions on your current grade, and on past month’s grades.
Demos are an integral part of the class. You should focus on giving polished demos that accurately reflect the progress you’ve made on your project. You cannot falsely represent your progress, or demo any functionality that has not been implemented. You must be forthcoming where you’re hard-coding aspects of your system (often necessary at early demos). Violating this will result in losing all credit for a demo.
In this course, you will be expected to deliver on all tasks assigned to you and to work independently on those, unless otherwise specified by instructions on this site. You coordinate can coordinate with students outside of your group only if explicitly allowed to do so by your SD Mentor or the SD Instructors. If you have any questions whatsoever regarding these policies, see us during office hours.
You may not, without permission from the instructor, exchange course-related code with anyone outside of your group (including anyone not registered in the course), or download code for use in your coursework, that you have not discussed and agreed upon with your SD Mentor. Likewise, you may not look at anyone else’s code outside of your group or show your code to anyone else outside of your group. Protect your work: for example, be careful not to leave printouts around.
If you use material in your assignments that are from outside the course material, then you should be prepared to explain that material. The instructors reserve the right to question you on your use of extraneous material. Failure to answer such questions might be viewed as grounds for an integrity violation, and will impact your grade.
Similarly, you must be able to explain all code in your project that you’re responsible for (i.e. that you committed). Inability to do so can be viewed as grounds for an integrity violation, and will impact your grade.
It is likely that you will use some external libraries or code in your project. You must properly attribute that code to its original source in your comments and documentation. The vast majority of the code specific to your project must be your own; if you are uncertain if you are using too much external code, meet with the instructor.
The Academic Integrity Code will apply to this course. Please read through the code carefully.
Penalties for violating the code or the policies described here include failing this course, and possible expulsion. They are elaborated in the Academic Integrity Code.

If you have a disability that may effect your participation in this course and wish to discuss academic accommodations, please contact us as soon as possible. You cannot expect accommodation for disabilities if you don’t contact us early, with enough time to plan, and maintain fairness for other students. You should see the schedule for the entire class, so if you anticipate any issues, please contact us about this in the first week of class.