CompSci 108
Fall 2009
Software Design and Implementation
SocSci

Meeting Time

MWF 10:05-11:20am in SocSci Room 229

Class attendence is required as class time will often involve participatory exercises, code reviews, or team meetings. You will also be expected to do a significant amount of reading, coding, and debugging outside of class time.

Course Staff

Professor Duvall Professor: Robert C. Duvall
  • LSRC room D228
  • rcd AT cs DOT duke DOT edu
  • 660-6567
  • Office Hours: Mondays 11:30am-1pm, Tuesdays 2:30-4pm, and Fridays 1-2pm
  • Drop-in policy: Feel free to come in whenever my office door is open; you may also make an appointment via email.
Jeff Martin Graduate TA: Jeff Martin
  • LSRC room D208
  • nedyalko AT cs DOT duke DOT edu
  • 660-4008
  • Office Hours: Wednesdays 4:30-5:30pm and Thursdays 1:30-2:30pm
  • Drop-in policy: Available outside of hours by appointment only.
  Undergraduate TAs
  • Alex Bradley
  • Sophia Cui
  • Ryan Echternacht
  • Kostadin Kostadinov
  • Lakshya Madhok
  • The Link, lower level of Perkins Library
    Since there is no specific spot in the Link where the UTAs will be, please check the Bulletin Board for announcements about their where abouts.
  • Office Hours

If you need to contact us via email, please put CompSci 108 at the start of your subject line. This will 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 Bulletin Board since it is seen by more people.

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. If you choose to buy any of these books online, please click on this link to buy from Amazon so that your purchase contributes to undergraduate Computer Science Research at Duke.

Java Books

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.

Grading

This is primarily a programming course, thus you must demonstrate that you have completed some programming during the semester in order to have a chance of receiving a passing grade. While your grade is based primarily on how well you do on several programming assignments, part of the grade is also based on written work that may be assigned during the semester and on class participation (specifically presentations, class discussions, and useful posts on the course bulletin board).

Note that your program's design and robustness each count for as much as completeness. 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 design them for future changes will result in a low overall grade. On the other hand, small bugs in some of the requirements will be tolerated if the design is extremely well done.

Types of Assignments

There are two kinds of programming assignment: individual and team assignments. Individual assignments are weekly projects, on which you must work by yourself. These assignments are designed to ensure that that everyone who completes the course is "certified" as capable of writing and understanding reasonably complex programs. As such, you must complete at least one such assignment in order to receive a passing grade for the course. In some cases, you will be asked to assess another student's mastery assignment in such a way that it factors into their assignment grade.

All other assignments are team projects. For the first project, teams will be chosen randomly. For the final project, teams will be based on your recommendations. This means that your team may not be an ideal mix of compatible personalities. As a team, it is your responsibility to idenitify problems as soon as possible and still plan to deliver a working program.

Note, only one summary grade will be given for each team assignment. 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 team's submission, each student must submit an individual project analysis after submitting the final version of the project. This analysis will not affect the team grade, but may impact your 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.

Often team assignments will have several smaller deliverables that must be submitted electronically before the final deadline. Each submission should show "real effort and achievement" towards the final goal. These submissions will be graded on a three point scale. One means that up to one point may be subtracted from your final project grade, two means a half-point may be subtracted, three means nothing may be substracted. Thus, if you get less than a three on any of these intermediate deliverables, you cannot earn more than a B+ on the assignment. Additionally, for each team assignment, one project artifact must be handed in.

A final team assignment will be assigned instead of a final exam. This final project must be completed and handed in before the course's scheduled exam time. Your final assignment will be presented in an open session, attended by your classmates, graduate students, and other faculty members during the scheduled exam period. Additionally, you may be assigned to meet with the professor as a group to demo your project and discuss its details. Plan on this demo taking approximately an hour --- everyone in the group must attend this demo.

Grading Weights

The percentages given below assume each of the projects above is assigned. If, during the semester, a project is not assigned, they may be updated to reflect their relative weight in the course. In short, these percentages are given as guidelines -- not fixed weights.

10% Class participation, written work
30% Individual projects
30% Team projects
30% Final team project

In general, to earn an A on any assignment you must go beyond what is expected. 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.

No Late Submissions

This class moves at a demanding pace and getting even a few days behind can be hard to recover from since, like a domino effect, each tardiness tends to propagate through the following assignments. Late work also makes extra work for the staff since we try to get things graded as soon as possible. Thus all projects must be turned in on time. If, for some reason, you (or your group) cannot meet a specific deadline you should hand in your best effort by the deadline. You should then to make sure to write a detailed project analysis, including what you would have done if you had more time and how you will avoid such problems in the future.

This may seem overly harsh, but it is important that you do not get behind in this course, its pace is too fast. 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 Computer Science courses. 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.

Submitting Projects

For each project you develop for this course, you must submit your program electronically, using the directions available here by the end of the day (i.e., 11:59:59pm) on the due date given. You are responsible for ensuring that all files are turned in on time. You may submit an assignment electronically as many times as necessary, but only the files included in the last submission will be graded. Thus, you should always submit all your project's source files --- even if they have not changed since a previous submission.

Submit only code (.java), text (.txt, .dat, or .xml), HTML (.htm, .html, or .css), PDF, image (gif, jpeg, or png) or sound (.au, .mp3, or .wav) files. You are free to use any programming environment available to complete your work, however, you are responsible for converting it into one of the standard formats listed above (most current programs can save or print files to a variety of alternate formats). All programs must use only standard code that runs on any platform (i.e., Windows, Mac OS X, and Linux); no platform specific code will be accepted.

Each project submitted must be accompanied by a README file that includes:

Additionally, each project must

Collaboration Policy

In accordance with the Duke Community Standard, we encourage proper collaboration, in which all parties equally participate, on programming projects and classwork. Quizzes and Exams taken online or in-class must be your own work; you should not collaborate on them at all. Studying together is always encouraged, especially when preparing for quizzes or exams. At other times you may be assigned to work in a group, in which there will be only one submission for the entire group that represents your collective effort.

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 classwork you may consult with other students only in a general way, e.g., about debugging, programming concepts, or questions about wording on the assignment. You cannot actively work with someone else unless the assignment specifically grants permission for you to do so. It is never acceptable to directly show one another your program code or write one program among a group and submit multiple copies. Finally, it is unacceptable to search for direct answers to problems on the Internet.

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. webpages, 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 will use Java 5 or above, the Eclipse programming environment, and the Duke Ambient plug-in for downloading and submitting projects. More information about installing this software is available here.

Online Course Information

Web Page
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 http://www.cs.duke.edu/courses/fall09/cps108/

Bulletin Board
You should regularly read and contribute to the course bulletin 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 bulletin 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.

Finally, please check your email regularly, as important course announcements may be sent via email.