Course Structure and Policies
Thomas J. Kennedy
1 Syllabus
All students are responsible for reading the course syllabus and abiding by the policies described there.
2 Course Structure
2.1 Sessions
- Lectures: online - no meeting times
- Recitations: Wednesday 7:10pm-9:10pm and Friday 1:00pm-3:00pm (selected weeks)
Recitations
Recitations will be used for special topics and for meetings with teams once the semester project is underway.
- They will not meet every week.
- Meetings will be on-line.
- You will attend from your “development machine”.
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:
- CS 350 (this course)
- CS 330 (Object Oriented Programming and Design)
- CS 333 (Accelerated CS 150/250)
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:
- Command line exercises (e.g., SSH Keys)
- Tool Set up (e.g., Installing compilers and Eclipse)
- Programming in Java (e.g., Unit Testing)
- 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:
- Writing Requirements
- Planning for construction: writing user stories
- Early construction: build management, version control, story tracking, project website
- Middle construction: configuration management, documentation management, continuous integration
- 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
-
I will assign you to a team, at random, for the first phase (Phase 1).
-
You will choose your own teams for the remaining phases
- Must be members of your recitation section.
2.4.2 Project and Recitations
The final three phases will be evaluated in part via a team meeting with the instructor.
- Held during recitation period
- Instructor will ask questions about team’s overall progress.
- The instructor may direct questions to specific team members to be sure that everyone shares an understanding of the project and required skills.
-
General rule is that if one member of a team does not know something, that’s a mark against that person. If two people don’t know something, that’s a mark against the entire team.
-
-
At end of some meetings, you may receive a short test/assignment, which each team member must complete individually within a limited time period (a day or less).
2.5 Exams
- Midterm & Final
- Administered on-line
- Dates & times on the course calendar
- Final exam is cumulative.
3 Course Pre-requisites
-
CS 252 (Introduction to Unix for Programmers)
-
and
- CS 330 (Object-Oriented Programming and Design), or
- CS 361 (Advanced Data Structures and Algorithms)
- Students who have not taken CS 330 are encouraged to take CS 382 (Introduction to Java) as a pre-requisite or, at the very least, to work through that course’s website during the first few weeks of the semester.
4 Communications
Contact Info
Instructor | Office | Phone # | Home Page & Office Hours | |
---|---|---|---|---|
Thomas J. Kennedy | Dragas 1100D | 757.683.7725 | tkennedy@cs.odu.edu | http://www.cs.odu.edu/~tkennedy |
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 and holidays within 48 on weekends & holidays.
Forums are also available on Blackboard for general discussions.
4.1 Office Hours
if true
My general office hours are available at https://www.cs.odu.edu/~tkennedy/. Instructions for scheduling a formal appointment are listed here. Note that my office hours include both live and web-conference based appointments.
Office hours are posted online
-
Available from http://www.cs.odu.edu/~zeil/officehours/
-
Meeting modes:
- face to face in my office
- Network conferencing (Google Meet)
- Telephone
4.2 Course Forums
- the Hallway
- for general discussion of course topics
- no discussion of assignment solutions!
- for general discussion of course topics
- the Janitor’s Closet
- reports of site issues, broken links, missing or incorrect web pages, etc.
5 Important Policies
5.1 Late Submissions
… are not normally accepted. Exceptions may be made in cases of
- documented emergencies
- arranged prior to the due date when possible.
Extensions to due dates will not be granted due to
- difficulties “porting” from one system to another
- transient system crashes
- system overloaded
5.2 Academic Honesty
ODU is governed by a student honor code.
- Everything you turn in for grading must be your own work.
- Students are expected to conform to academic standards in avoiding plagiarism.
- Detailed policy statement is in the syllabus.
Academic Honesty (cont)
- Aiding a fellow student to copy someone else’s work (including your own) places you equally in violation.
- Includes leaving work world-readable on the computer system!
- Failure to report observed violations of the honor code is also a violation.
- Aiding a fellow student to copy someone else’s work (including your own) places you equally in violation.
- Includes leaving work world-readable on the computer system!
- Failure to report observed violations of the honor code is also a violation.
5.3 Grading
Assignments: | 15% |
Semester project: | 50% |
Midterm exam: | 15% |
Final exam: | 20% |
6 Course Themes
Questions
- What is “Software Engineering”?
-
What is “Engineering”?
-
Is there “engineering” in software development?
-
6.1 Goals
- Look at best practices from the open source world.
- What are the tools and techniques that developers use on a daily basis?
- Automate best practices.
- Make it more trouble and more time consuming to do things wrong than to do them right.
6.2 Areas of Emphasis
- Teamwork
- Test-Driven Development (JUnit)
-
Build Management (Gradle)
- Version Control (Git)
- Configuration Management (Gradle)
- Documentation Management (Javadoc)
6.2.1 Teamwork
- Reaching and recording agreement
- Collaborating without conflict.
- Visibility & communication
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.
-
A good build manager will not only compile and link the source code…
-
It will also run the tests
- making it more difficult to not test after every change
-
and update the documentation and reports
- again, actually requiring the programmer to work harder to let these things get out of sync than to keep them up to date
6.2.4 Version Control
The ability to track changes in the software.
- Avoid accidents
- resolve conflicting changes
- Explore ideas, then discard ones that turn out to be undesirable
6.2.5 Configuration Management
- How do we cope with importing third-party libraries that are themselves changing and have version depencies among themselves?
- How do we cope with dependencies of our own software upon the underlying platform?
6.2.6 Documentation Management
- Integrating documentation into the development process,
- minimizing the “chore”.