CompSci 308
Fall 2018		 Software Design and Implementation

Meeting Time

Tuesday 4:40-5:55pm in Gross Hall room 103
Thursday 3:05-5:55pm in Gross Hall room 103

Class attendance is required as class time will often involve participatory exercises, code reviews, or team meetings. In particular, Thursday's combined lecture and recitation meetings will be used to practice important concepts discussed during the week. You will also be expected to do a significant amount of reading, coding, and debugging outside of class time.

Course Staff

Professor Robert C. Duvall
  • LSRC room D228
  • rcd AT cs DOT duke DOT edu
  • Office Hours: Tuesday 3-4pm, Wednesday 3-4pm
    I am generally not available during the weekend
  • Drop-in policy: Feel free to come in whenever my office door is open; you may also make an appointment via email.
Graduate TA Chengkang Xu
  • North room N003
  • cx88 AT cs DOT duke DOT edu
  • Drop-in policy: You may make an appointment via email.
  Undergraduate TAs
  • Madeline Briere
  • Jeremy Chen
  • Susie Choi
  • Matthew Dickson
  • Charlie Dracos
  • Diane Hu
  • Gordon Huynh
  • Ashley Meuser
  • Conrad Mitchell
  • Matthew O'Boyle
  • Elizabeth Shulman
  • Ashka Stephen
  • Rayan Tofique

Email is the best way to contact the course staff if you have a personal concern. When using email, please put CompSci 308 at the start of your subject line to help ensure that your email gets past our spam filters and is delivered correctly. If you send us an email and do not get a response within 24 hours, we probably did not receive it. In general, you should only email us about administrative aspects of the course; questions about course content are better made using the course Discussion Board since it is seen by more people.

Our goal is simple: to help you learn — both inside and outside the classroom. If you have questions, there is no excuse for not getting help. We meet with you regularly for the purpose of helping you. If you have a problem or question, we want to talk about it — do not put it off.

Books

Most of the readings assigned during the semester will be excerpts from books or online articles. However, many students also like to use a reference book about advanced programming topics, so the books listed below are optional. There is lots of information available online, but the books below are rather complete in their coverage.

Java Programming
Program Design
Teamwork and Project Management

In general you should do the readings in order to be prepared to ask and answer questions in class. Reading quizzes may be given at the beginning of class to ensure that you have looked at material before it is discussed. On days where no quiz is given, time will be given at the beginning of lecture for you to ask questions about the reading. The majority of class time will be an extension of the reading, not a summary.

Topics

The following topics will be covered during the semester.

The exact order and details of these topics will be given on the course Calendar, which is subject to change during the semester based on the pace needed. Additionally, we may explore collateral topics as dictated by class interests.

Grading

This course is about the creation of software in teams, thus it is much more than simply a programming course. To receive a passing grade, you must demonstrate both that you have completed significant programming and that you have been a successful part of a team. This emphasis is reflected in the grading weights below that give equal weight to the programming assignments and “soft-skills” needed to survive as a software developer.

 25%   Engagement: consistent participation in class and on-line discussions, in your team-work, and in your regular meetings with the course staff
 25%   Skills: consistent improvement in coding, designing, and project planning and management
 50%   Assignments: individual, team, and final project grades

Grading Weights. The grading for this course is more like a humanities course than a standard CompSci course. In truth, when grading large software projects, I often feel more like I am grading essays than I do a Computer Science professor testing whether a program simply works or not because my job is to determine how much thought went into your project. Grades are determined by a combination of criteria that, to you, may seem to border on pure subjectivity. Each software project will be graded in the following general categories (as well as project specific "checklist" criteria):

 30%   Design: how well designed is the project?
 20%   Craftsmanship: how clean and readable is the code?
 20%   Quality: how robust is the project? how well tested?
 15%   Completeness: how well does the project work?
 15%   Documentation: how well is the design documented and justified?

Design Counts. Note that your program's functionality counts among the least percentages. This implies that a solid, working sub-set of the complete program, with a design that clearly supports easily adding the remaining functionality, will receive a higher grade than a completely functional program that was hacked together at the last minute and was not obviously tested. Unlike in other Computer Science courses where the program's functionality is primary, this course focuses on program design. In fact, the project requirements are usually chosen to highlight a specific set of design ideas. Simply implementing all of the requirements without evidence you have thought about how to they are integrated into a complete design will result in a low overall grade. On the other hand, small bugs in some of the requirements will be tolerated if they are documented and the design is well done.

Teamwork Counts. One summary grade will be given for each programming project. Thus your individual grade depends not only on your programming skills but on your ability to work with others. More credit will be given to programs that have minimal, but collaborative, functionality than to projects that have one piece working perfectly, but do not represent the integrated efforts of the team. In addition to the final submission, each student must submit an individual project analysis after submitting the final version of the project. This analysis does not affect the team grade, but is weighted equally as an individual grade. For example, if the team project fails, despite your best efforts, but you write a good, concrete, and detailed analysis of why it failed you may receive a D on the project, but an A on the analysis.

Peer Evaluation Counts. Teams will be chosen for you based solely on schedule compatibility (except for the final project, where you may choose your own team). This means that your team may not be an ideal mix of compatible personalities. As a team, it is your responsibility to identify problems as soon as possible and still plan to deliver a working program. You will be asked to assess yourself and your fellow student's participation in the team in such a way that it factors into their final grade.

Overall Weighting

The last month of the semester will be spent creating a large software project involving approximately ten students built on top of open source projects with student built modules that are refined and extended through multiple draft releases. This project is the focus of the course and is given in lieu of a final exam and must be completed and handed in before the course's scheduled exam time. This project will be presented in an open session, attended by your classmates, graduate students, and other faculty members during the scheduled exam period.

Practice Counts. The percentages given below reflect each project's relative weight in the course. In other words, the projects leading up to the final project are like practice before the main event: a necessary place to learn from your mistakes before they really count.

 20%   Individual work (coding projects, written work, or discussion board posts)
 30%   Small team projects (in preparation for the final project)
 50%   Final team project (the focus of the course's second half)

Just Effort Does Not Count. I do not give grades: students earn their grades. It is your responsibility to earn the grade you desire. In general, to earn an A on any assignment you must go beyond what is expected. Simply meeting all requirements is worth only a B+. Meeting all requirements superbly can earn an A-. Doing more than is required, or doing astonishingly good work, is the only way to earn an A. Graded items will be scored using a "checkmark" system through regular meetings with your UTA mentor. Past experience with this course indicates that students are pretty consistent in their performance and that it is easy to assign grades. I will be looking for a record of sustained effort and demonstrated comprehension of the subject matter.

No Late Submissions

All projects must be turned in on time. If, for some reason, you (or your team) cannot meet a specific deadline you should hand in your best effort by the deadline. You should then make sure to write a detailed project analysis, including what you would have done if you had more time. Making significant contributions to a project after the deadline is considered cheating and will result in a loss of that project's grade.

This may seem overly harsh, but it is important that you do not get behind in this course, its pace is too fast and getting behind even a few days can be hard to recover from since, like a domino effect, each tardiness tends to propagate through the following assignments. Additionally, it allows us to give you feedback as quickly as possible. The secret to successfully surviving this course is to start early and work steadily; it is not possible to cram or skim in this course. If you are having trouble, be sure to see one of the course staff as far before the due date as possible. Do not give up, ask for help.

Individual extensions will be granted only for medical reasons (see the Short-term Illness Notification policy) or other circumstances beyond your control that must be presented with an official Dean's excuse. Extensions will not be granted after an assignment is due, you must request an extension well before an assignment is due.

Collaboration Policy

In accordance with the Duke Community Standard, we encourage proper collaboration, in which all parties equally participate, on programming projects and class work. Individual work must be your own work.

You are responsible for understanding all work you turn in. For any given assignment, an interview may be included as part of the graded work. During the interview, you may be asked to explain the problem solving process and individual lines of code not given as part of the assignment. Turning in code that you cannot explain is considered cheating.

You may consult with the course staff about any aspect of the course. On programming projects and class work you may consult with other students in a general way, e.g., about debugging, programming concepts, or questions about wording on the assignment. Studying together is always encouraged but you may not actively work with someone else unless the assignment specifically grants permission for you to do so.

Specifically, it is unacceptable to

You may use small pieces of properly attributed code from online sources or open source projects as long as that code

Consult means you can discuss programs in a general way before writing code and get help with debugging your program, but you must write your own code and do your own thinking about the problem. For each assignment you are expected to include a list of the people with whom you have consulted (including any other students and course staff) in the README file you submit with the assignment. You should also cite any resources other than class materials you use (e.g. web pages, notes from other courses at other universities, etc.). This file is required and failure to provide it will result in rejection of the assignment as complete.

If you are not sure what the collaboration policy is for a given assignment, please ask!

Computing Requirements

All computing projects should use Java 10, the IntelliJ programming environment, and Git Version Control. We will use the most modern UI toolkit provided with standard Java: JavaFX; but not any of its add ons that build the code for you (specifically, we will not be using FXML or the separate tool, SceneBuilder, at all in this course).

A laptop is strongly recommended (so you can bring it to class and meetings with course staff). Access to and on-going use of a computer on which you can install software.

Online Course Information

Web Site (http://www.cs.duke.edu/courses/fall18/compsci308/). Many of the materials for this course, including the syllabus, class notes, reading assignments, homeworks, and other resources, will be available through the course web page at

Discussion Board (http://piazza.com/duke/fall2018/compsci308/home). You should regularly read and contribute to the course discussion board as it is a useful place for posting questions that are likely to be of interest to the rest of the class. You are encouraged to post responses to questions as well as ask them. The discussion board will be monitored regularly and responses posted to questions that have not previously been answered. Before posting a question, please make sure that you have read all previous messages and that your question has not yet been discussed.

Email. Please check your email regularly, as important course announcements may be sent via email.

Copyright 2018 Feedback?