Course Structure and Policies

Thomas J. Kennedy

Last modified: May 13, 2020

1 Syllabus

All students are responsible for reading the course syllabus and abiding by the policies described there.

2 Course Structure

2.1 Sessions


Recitations will be used for special topics and for meetings with teams once the semester project is underway.

Recitations will be used for informal individual meetings and group meetings. All dates will be specified in the course outline.

2.2 Review Recordings


I provide recorded Reviews on the course site. These are, in general, condensed versions of what would traditionally be live lectures. This includes:

As a general policy I make all three sets of reviews available to CS 350 and CS 330 students. You will find direct links to CS 350 Review Recordings throughout the outline. I will update these reviews throughout the semester (as necessary).

2.3 Assignments

Individual assignments (3 attempts each). Assignments will include:

  1. Command line exercises (e.g., SSH Keys)
  2. Tool Set up (e.g., Installing compilers and Eclipse)
  3. Programming in Java (e.g., Unit Testing)
  4. Version Control (e.g., Git)

This a non-exhaustive list.

2.4 Semester Project

A moderately large program on which you will work in teams of 4-6 people.

Five phases:

  1. Writing Requirements
  2. Planning for construction: writing user stories
  3. Early construction: build management, version control, story tracking, project website
  4. Middle construction: configuration management, documentation management, continuous integration
  5. Later construction: integration testing, analysis tools

In general, you will be evaluated upon process as much as upon you ability to produce working code.

The idea is to see if you have established a team process such that, if you had enough time, you would have eventually implemented the entire process.

2.4.1 Project Teams


2.4.2 Project and Recitations


The final three phases will be evaluated in part via a team meeting with the instructor.

2.5 Exams

3 Course Pre-requisites

4 Communications

Contact Info

Instructor Office Phone # Email Home Page & Office Hours
Thomas J. Kennedy Dragas 1100D 757.683.7725

Important: The course name “CS350” should appear in the subject line of all course-related email.


I try to respond to all (properly marked) messages before I leave campus each day (Monday through Friday). On weekends & holidays you can usually expect a reply within 48 hours.

Forums are also available on Blackboard for general discussions.

4.1 Office Hours


My general office hours are available at Instructions for scheduling a formal appointment are listed here. Note that my office hours include both live and web-conference based appointments.

4.2 Course Forums

5 Important Policies

5.1 Late Submissions

… are not normally accepted. Exceptions may be made in cases of

Extensions to due dates will not be granted due to

5.2 Academic Honesty

ODU is governed by a student honor code.

Academic Honesty (cont)

5.3 Grading

Assignments: 15%
Semester project: 50%
Midterm exam: 15%
Final exam: 20%

6 Course Themes


6.1 Goals

6.2 Areas of Emphasis

6.2.1 Teamwork

6.2.2 Test-Driven Development (TDD)


Exemplified by the philosophy of “write the tests first, then design and write the code.”

This is easily justified when fixing bugs. You need to have a test handy that shows the bug causing the program to fail, so that you can run it (again and again) while you try to fix the bug. How else will you know that you have it fixed?

But test-driven development is really about how to do the initial design. Programmers are often lazy. If they write the code first, they often skimp on the testing because that seems like too much work for code that they are “sure” is correct. (Remember, all programmers are optimists – they always believe that their code is going to work “as soon as I fix this one bug”. The combination of unjustified optimism and laziness can be deadly!)

But if the tests are already there, and if it’s easy to run them (or, even better, hard not to run them – I’ll talk about that in just a moment), then programmers will actually do the testing on a regular basis.

And thinking about tests for special/boundary cases, etc., often helps you remember those cases when later doing the design and coding.

6.2.3 Build Management

Making sure that you and others can build the system easily.

6.2.4 Version Control

The ability to track changes in the software.

6.2.5 Configuration Management

6.2.6 Documentation Management