1 What This Course is About

1. How developers collaborate in teams to produce projects that are too large or too complicated for a single developer.
2. The tools and processes that facilitate that work.
3. Best practices, as accepted by the programming community, that developers on a team expect from their peers.

2 This Class is Different

…from most of your prior CS courses.

2.1 Specifications

• In CS 150, 250, 330, 361, etc., you were given detailed instructions on what your programs were supposed to do.

• In this course, you will be writing those detailed instructions.

  • And your source material will be ambiguous, contradictory, misleading, and messy, just like in real life.

2.2 Testing

• In CS 150, 250, 330, 361, etc., the instructor designed and ran tests to check if your code was working or not.

• In this course, you will be writing those tests.

  • And you may find that, just like real software developers everywhere, you spend as much time working on the tests as on the actual code.

2.3 Process

• In CS 150, 250, 330, 361, etc., the primary goal of your programming work was to produce working code.

• In this course, your primary goal is to demonstrate an effective process for eventually producing working code.

  • You will be graded on process more than on the final product.

3 Syllabus

3.1 Course Pre-requisites

4 Course Structure

4.1 Sessions

• Lectures: online - no meeting times
• Recitations:
  • T 10:00-12:00 (Zeil)
  • T 1:30-3:30 (Decker)
  • W 10:00-12:00 (Decker)
  • W 7:10PM-9:10 (Zeil)
• Weekly Q&A session (optional)
  • Survey in Canvas to select a time.
  Lecture materials for this course will be available on-line, primarily in printed/text form.

4.1.1 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”.

5 Activities

Each module in the course outline contains a variety of activities.

• Not all are graded.
• But unless specifically stated otherwise, all are required
• And should be completed by the end of that module

5.1 Readings

• lecture notes
• textbook chapters & web articles

All are online and available via the course Outline.

5.2 Assignments

Individual assignments will include:

1. Clean Coding
2. Unit Testing
3. Version Control (git)
4. Test-Driven Development
5. Build Manager (gradle)
6. Continuous Integration (Github Actions)

Most of these provide practice or actual infrastructure for use in the project.

5.3 Labs

There are a number of activities marked in the outline as “Labs”.

• These are graded, but low-stakes activities.
• Many of these play directly into a later assignment.

5.4 Semester Project

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

Five phases:

1. Writing Requirements
2. Planning for construction: writing user stories
3. Sprint 1: build management, version control, story tracking,
4. Sprint 2: project website, documentation management
5. Sprint 3: continuous integration, system testing

• In general, your team will be evaluated upon process as much as upon their 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.

• The team score will then be modified for individuals based on evidence of teamwork.

5.4.1 Project Teams

• Teams will be assigned randomly.
• Each team will draft a contract defining their expectations of acceptable participation.
• There will be options for voluntarily leaving a team, and for being fired from a team.

5.4.2 Project and Recitations

Phases 3 and 4 will be evaluated in part via a team review meeting with the instructor.

• Held during recitation period
• The 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.

• On rare occasions, at end of the meeting you may receive a short test/assignment, which each team member must complete individually within a limited time period (a day or two).

5.4.3 Expectations

The team project is a integral part of this course.

• Students are expected to actively participate in and contribute to their teams.

  • This engagement with the team will be part of the grade.
  • It is possible to be fired from a team if your teammates believe that you are slacking.

• Procrastination and deadline-brinkmanship are detrimental to any team dynamic.

  • Students who work early and often will be rewarded.

6 Exams

• Midterm & Final
  • Administered on-line
  • Dates & times on the course calendar
• Final exam is cumulative.

7 Communications

• Communications with the instructor
  • Email
  • Optional, CS350 channel in the CS/STEM Discord
  • Office hours (refer to syllabus)
• Communications with your project team
  • Email
  • Discussion board in Canvas
  • Regular team meetings are strongly encouraged
    • The recitation time slot is available most weeks
      • Teams may, at their discretion, invite the instructor to such meetings.

8 Important Policies

8.1 Late Submissions

• Assignments that are are automatically graded will be accepted up to two days late, at a penalty of 10% per day.

• Other 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

8.2 Academic Honesty

ODU is governed by a student honor code.

9 Course Themes

Questions

• What is “Software Engineering”?

  • What is “Engineering”?

  • Is there “engineering” in software development?

9.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.

9.2 Areas of Emphasis

• Teamwork
• Test-Driven Development (JUnit)
• Build Management (Gradle)
• Version Control (Git, GitHub)
• Configuration Management (Gradle, JCenter)
• Documentation Management (Javadoc, PWD, SpotBugs, JBake)
• Continuous Integration (GitHub)
• Agile development (OpenProject)

9.2.1 Teamwork

• Reaching and recording agreement
• Collaborating without conflict.
• Visibility & communication

9.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.

9.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

9.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

9.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?

9.2.6 Documentation Management

• Integrating documentation into the development process,
  • minimizing the “chore”.

9.2.7 Continuous Integration (CI)

• Offloading repetitive & time-consuming activities to remote servers.
• Set up and manage a CI server on Amazon Web Services (AWS)