CSCI 4243W - Senior Design

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

Course Info

Instructors Contact info:

• Gabriel Parmer
• Rahul Simha
• Chris Toombs

Fall 2017 Class Time/Location:

• Project Updates and Sprint Planning Meetings: Tuesdays 2:00-3:15PM and 3:30-4:45, TOMP 402
• Lectures, Presentations, and Demos: 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

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.

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.

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 Review. Every month, you can optionally submit a Group Review 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 a group review, to remind people to use this mechanism, you should feel free to send a group review anytime you feel it is necessary. If you have not sent us group reviews, 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 a Group Review. Please email your SD Mentor using the title “SD: Group Review”. Include your group review 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

1. 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.
2. 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.
3. Making steady commits and pull requests to your repository. Your grade can be negatively impacted by a lack of steady commits and progress.
4. 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.
5. Your presentations must show progress over the year, and must address the feedback provided to you after each presentation.
6. The final product.
7. Participation in all class activities. This involves coming to classes, and being active in them.

Grade breakdown.

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

Fall semester grade. At the end of the Fall semester, you will be given an IPG (In-ProGress) grade, which mean that your final grade at the end of spring will count for both semesters.

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.