Instructors: Timothy Wood, Xiaodong Qu, Josh Shapiro
Email: timwood@gwu.edu x.qu@gwu.edu jshapiro314@gwu.edu
Prerequisites: Senior status, CSCI 3212, CSCI 3411

Time/Place:

  • Class meets: Tuesday 2:00–3:05pm Tompkins 201 (Section 10) or Tuesday 3:35-4:40pm SEH 1300-1400 (Section 11), and Wednesday 6:10-8:40pm SEH 1300-1450(Lab)

Office Hours:
Check Slack for most updated ones.

Online Platforms

  • Slack for one on one communication with instruction team, mentors, discussions, announcements
  • Blackboard (Grades, Writing Homeworks)
  • Github (project repo, code, project webpage, sprint planning)
  • Google drive (uploading videos); you can also link to a youtube account if you have one.
  • Webpage - course slides, recordings, tutorials, links to software

Project (Technical) Mentors
Each team will have a technical mentor assigned to them, and is required to meet regularly with their mentor. We recommend a weekly meeting but bi-weekly meetings, and sprint planning meetings, are required. The mentors are a valuable resource and they will help teams develop, evaluate, design, implement and test the projects. Mentor feedback will be an important part of your assessment. See the complete list of technical mentors list on Course webpage.

Course Description and Learning Outcomes

This is the capstone project two course sequence. Bulletin Description: Planning, design, and construction of the capstone project; economic analysis of the project; application of software engineering principles, including software requirements, specification, requirements engineering, reuse, documentation, verification/validation, testing, configuration management. Includes a significant engagement in writing as a form of critical inquiry and scholarly expression to satisfy the WID requirement.

Learning Outcomes:

  • Learn industry best practices, tools, and key elements in the software development process through a year-long computer science project: research and discovery, planning and design, development and launch.
  • Apply concepts from software engineering to the project: requirements, specifications, reuse, documentation, verification and validation, testing, configuration management.
  • Learn to communicate (written and oral) your work to stakeholders of the project: the case for launching the project, status reports, design, implementation plan, and demos.
  • Demonstrate an understanding of the concepts that you’ve learned in your Computer Science curriculum, and how knowledge and skill in Computer Science courses played a role in the project.
  • Explore local and global impact of computing, as well as social impact issues.
  • Demonstrate a working project

Schedule and Course Outline

Topics

Topics covered in the course (during lectures, tutorials, discussions, panels, mentor meetings) include:

  • SW Engineering Methodologies and Processes
  • Project Planning: Discovery, Research and Planning in Practice
  • SW Developer tools
  • Project Development and delivery
  • Design and User experience
  • Communication skills - written reports, oral presentation skills (presenting to different audiences)
  • Teamwork: roles, communication and collaboration
  • Career planning: mock interviews, career paths

Textbook and Resources

There are no textbooks for this course. Each project team is expected to identify and install the software necessary for completion of their project.

Class Meetings

The course is structured to have several types of (non-standard) meetings during each semester. At the high level, these different types are:

  • Lectures/presentations/Demo/Interviews: These are held during the scheduled Wednesday class sessions.
  • Standup meetings: A Standup Meeting (Agile methodology) is a weekly high level project status meeting between the team and the project instructor/mentor. Each team will meet with their technical mentor and/or course instructor for their standup meeting. During this meeting, we ask our team members three types of question, in order to most efficiently make progress on the project. See Course Main page for more details.
  • Sprint Planning Meeting (SPM): A Sprint Planning Meeting (Agile methodology) is a monthly meeting in which the team sets the goals and tasks they choose to commit to for the next month. The group determines which Backlog items will be handled in the next sprint. These are documented using Github Projects. Teams should come to these meeting with all the cards they will work on for the following month.

Assessments (Requirements)

  • Submit all assignments/deliverables in the specified location; code on github, project updates on github projects, writing on Blackboard, videos on shared drive (or Github) etc. Submit Group Feedback by google form (see “Group Feedback” below).
  • As you plan your sprints, keep in mind anyone taking vacation, school holidays or breaks, or other major events to plan into your schedules.
  • Your mentors are there to help guide you through your projects, help unblock you when you’re stuck on anything, and report back to your instructors on your progress.
  • Your Github Project Board is your source of truth on task progress. Your goal is to move all tasks from Idea to Code Complete as efficiently as possible. If your Github Project Board isn’t updated, your mentor has no way to gauge your progress and help you move forward.

Written Assignments

Writing assignments help you practice communicating your idea and putting it into a broader context. Whether in industry or in academia, you’ll need to “sell” and communicate your idea to someone willing to support it. The writing assignments have the deadlines specified in the schedule and requirements linked from the schedule. You will use Blackboard to submit your individual written assignments; final design documents will be submitted in your Github project repo.

Presentation Assignments

Senior design enables you to focus on your own project, and push your technical capabilities through it. However, it is very important to learn how to successfully communicate (verbally as well as written) what you’re doing, and why it is cool with the outside world. It isn’t enough to technically complete your project. You also need to sell it! Presentation skills are very important and relatively rare in graduating undergrads. Thus a good portion of SD will focus on your presentation skills, and will include presenting to different audiences. The presentation deadlines and requirements will be specified in the course schedule. You will use Github and/or google drive to submit your final team project presentations.

Demos (Checkpoints)

There are four substantive demos (you can view these as major project checkpoints) during the two semesters (Fall and Spring). As part of your project planning (early in fall) the mentors will help you identify the deliverables/demo for each of these checkpoints and we assess your progress based on this. To meet requirements each of the four demo/checkins, must have implemented some part(s) of your final software system (therefore a report or a design document by itself will not meet the criteria for any of the four checkpoints).

  • 1: Alpha Prototype
  • 2: Beta Prototype
  • 3: Prototype Preliminary Demo
  • 4: Final Demo

Final Package

To complete the course, you must submit the Final package by the deadline May 11th. Failure to submit the complete final package will result in no grade being assigned
You must submit the following:
1. Code (Github repo) Please check with instructor or your faculty mentor to see what your specific requirements are.

  • The most recent working version of your project’s code, merged to main (on Github project repo)
  • A README file that explaints how to install all libraries needed, what paths need to be set up etc to get your project running.
  • README file should also contain instructions for follow-on projects (for future SD projects) if applicable.
  • (If applicable) A simple test program that can be run at the command-line that will run only if everything is correctly installed

2. Equipment (if applicable): If your project involved equipment bought by the Department, please return the equipment before noon on May 12th

3. Project Videos (Screencasts) You will need to submit two videos (on Github or your google drive which you must share with the instruction team and your mentor.

  • Create a 3-5 minute “promotional” video that is akin to a “sales pitch” (plan for a 3 minute video, and you should not exceed 5 minutes). It should provide a high level description of your project/product aimed at general tech savvy audiences (such as VCs, upper level management, etc.). It should describe what the product does and why is it useful - you don’t need to describe how it is built.
  • Create an 8-minute project video (it can be a 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 and understand what the project does, as well as how it works (including technical components and solutions). We recommend including videos (or at least screenshots) showing your project at work.

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

5. Project Webpage Create one professional website for your project, hosted on github (see main course page for link to github pages) with the following elements:

  • Landing page (home page) - should have an “about” content which gives a concise description of your project; visitors to the website should get an idea of what your project does just by reading this.
  • Team information - include photos and short (one paragraph) biosketch about each team member (interests, position etc.).
  • What tools/libraries/APIs/hardware were used to build your project (this info should ideally be part of the landing page)
  • (Links to) Your Two videos (promotional video and project description video).
  • Links to the following:
    – The executive summary (elevator pitch) writing assignments from Fall.
    – Link to a page/document that describes your software architecture
    – Your poster

Teamwork and 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 & instructor with title “SD: Group Problem”.
Group Feedback / Teamwork Survey Every month, you are required submit feedback to your SD mentor & instructor. These reviews are an opportunity to raise any concerns you have with your group. Suggested topics you likely want to include in your review:

  • How you are performing within the group
  • How others in your group are performing in your perception.
  • Any evidence (eg. commit history) to support your claims.
    Your SD instructor(s), sometimes including the 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, it will be near impossible for us to act on that. 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.
    Submission of Teamwork Survey Forms. These are required and links will be posted in class in the week they are assigned.

Workload

The course, each semester, will be taught using a combination of in-person lectures, remote lectures, remote or/and in-person meetings with project mentors, and recorded videos or notes. Each semester (in each of the two course sequence), you are 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. This does not include any preparatory work you may need to come up to speed with software tools such as Github, Slack, etc..

Grading:

Your grade in this class (courses) will be determined by a number of components:

  • Your Github Projects Board Each weekly “standup” will consit of a check-in of your Sprint progress. At the end of the sprint (approximately one month), you will receive a grade based on your:
    – size of the commitment you make at the beginning of each sprint and appropriateness of refinements throughout the Sprint.
    – Completed tickets and demo-able code. The goal of each Sprint is to have demo-able code, hitting your next achievable milestone. Your demos should reflect reflect the current state of the project’s work on the Github Projects Board.
    – Progress on Incomplete or In Progress tickets.
    – Teamwork assessment and contributions.
  • Your Github repo Making steady commits and pull requests to your repository. Your grade can be negatively impacted by a lack of steady commits and progress. We will only evaluate code merged to main.
  • Your writing assignments Each writing assignment is graded separately, and contributes 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 in class activities This involves coming to classes, and being active in them (includes discussing tools, suggestions for other team projects, etc.)

You will be assigned grades for each course CSCI 4243 and CSCI 4244, with the following grade breakdowns:

CSCI 4243 (Fall semester)

  • [35%] Presentations
    • [5%] Presentation 1
    • [10%] Presentation 2
    • [20%] Presentation 3
  • [20%] Writing assignments and design homeworks (5% each)
  • [20%] Sprint Progress: 20% weekly status updates, sprint boards, code commits, website, resume
  • [20%] Alpha Project Review
  • [5%] Participation and Initiative: attendence, team surveys

CSCI 4244 (Spring semester)

  • [20%] Presentations and Webpage
    • [5%] Presentation to general audience (commerical presentation)
    • [5%] Mock demo presentation
    • [10%] Webpage
  • [30%] Sprint Progress & Demos
    • [10%] Demos: will take into account progress since previous demo, technical complexity (including tools used)
    • [20%] Sprints: weekly status updates, sprint boards, code commits. Additional focus for Spring is Testing and Code review.
      • For fall, sprint grading will be: 4% September, 6% October, 10% November/December
  • [35%] Final project demo/presentation: The grade is based entirely on the final project and presentation.
    • [10%] Formal Presentation: this is the formal presentation (business casual) at end of the semester to an open audience (open to all CS students, faculty and alumni) in Lehman Auditorium
    • [25%] Final Demo: this is the full demo of the final project/product. Grade based on their project scope, technical scope, and amount completed.
  • [5%] Participation and Initiative: attendance, team surveys
  • [10%] Final Package: All requirements must be met (including written report, code documentation, screencasts, webpage)
    • Webpage
    • Screen Recordings (linked from webpage), the commerical (elevator pitch) recording and technical product recording
    • Documents (final report, code documentation)
    • Poster and poster presentation

Note on grading

You will notice that at the end of the Fall semester, you will be given a grade that is heavily weighted based on
– how well you did on written assignments
– how well you set and completed spring goals
– how well your goals set you on track for a launchable project in the Spring, 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 semeter grade is based on the same factors (with different weights), but also on the final quality of your project. It is important to understand that your Spring semester grade can be different from your Fall semester grade.
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” in this document.
Grades will be posted on Blackboard, and feedback will also be available on Slack and Trello

Course Policies

Falling behind in Senior Design

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.

Late Work policy

  • Writing Assignment Late policy: late writing assignments will yield credit with 10% penalty per week until the next writing assignment is due at which point, it will not be accepted.
  • Other Assignments: will receive 50% credit if submitted before the end of the sprint.
  • Submission of all assignments must follow the submission rules above. All reports, presentations and such will be submitted via your Blackboard or Github or project website and via google drive as a pdf, as specified in each assignment.
  • 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 (on Github, google drive, blackboard etc.).
  • The only exceptions, for late work submission, are due to (documented) medical or family emergency or instructor approved technical delays (such equipment delays/malfunctions, mentor availability, etc.). But you need to contact the instructor(s) beforehand.

If you have a disability, or a health or a family emergency, that may effect your participation in this course and wish to discuss academic accommodations, please contact the instructors soon as possible. You cannot expect accommodation for disabilities if you don’t contact us, 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.

Email policy: We recommend using Slack for any communication regarding the project itself. For personal communication (team issues, personal emergencies, etc.) you can send email to our GW email addresses.

Illness policy: If you are ill and it will cause you to miss class, lab, or an assignment, you should let the instructors know in advance if possible. We cannot extend deadlines unless you contact us. You are still (eventually) responsible for all material you missed. It is your responsibility to communicate with your team in such instances.

Classroom Policies and Responsibilities

This is a course that requires both substantial independent work as well as frequent interactions with the mentor and instruction team. Furthermore, your project requires working in a group. It is important that you follow the policies below which are designed to provide a conducive environment for all students in the class.

  • Be respectful to your classmates
  • Working on other tasks during your team meetings (with mentor and/or with other team members) is not allowed. This shows a lack of respect for your teammates and to the mentors (who are volunteering their time to help you with the project).
  • Be respectful towards the instruction/mentor team and be cognizant of their time (they have other responsibilities, committments and a busy schedule).
  • Remember: poor planning on your part does not constitute an emergency on our part

Responsibilities

  • Conduct your online behavior in accordance with the class “Online Social Contract”
  • Attend all classes/meetings unless you are sick or if there is emergency in which case you must contact the instructor(mentor) before class (meeting).
  • Interact, ask questions and generally paricipate in class discussions
  • Be respectful when working in a group, and make sure that everyone’s ideas are heard and taken seriously
  • complete all work in accordance with academic honesty rules for the university and for the class
  • Work to digest and process all provided material including reading assignments
  • Contact the professor if you are worried about completing the assigned work
  • Share feedback on the course progress with any of the instruction team
  • Treat instruction team with respect and be cognizant of their time (do not make unreasonable or last minute demands on their time)

Justice, Equity, Diversity, Inclusion (JEDI) statement
The instructional staff intends for this class to serve the needs of all students. The diversity of perspective and background of the students and instructional staff will be treated as an asset, and you are encouraged to bring your thoughts on how we may do better to the main instructor. See JEDI resources
 for student resources.

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 Github Projects 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 Github Projects 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 Github Projects 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 GW Academic Integrity Code and CS policies 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

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 are elaborated in the GW Academic Integrity Code. Note that the minimum punishment is failure of the assignment.

Support for Students outside the Classroom

  • Academic Commons. Academic Commons provides tutoring and other academic support resources to students in many courses. Students can schedule virtual one-on-one appointments or attend virtual drop-in sessions. Students may schedule an appointment, review the tutoring schedule, access other academic support resources, or obtain assistance at academiccommons.gwu.edu.
  • Disability Support Services (DSS) 202 994 8250. Any student who may need an accommodation based on the potential impact of a disability should contact Disability Support Services to establish eligibility and to coordinate reasonable accommodations. disabilitysupport.gwu.edu
  • Counseling and Psychological Services. 202 994 5300. GW’s Colonial Health Center offers counseling and psychological services, supporting mental health and personal development by collaborating directly with students to overcome challenges and difficulties that may interfere with academic, emotional, and personal success. See Health Center.