1 Course Structure

1.1 Sessions

• Lectures: Tues & Thurs, 3:00-4:20, Room: Health 2008

• Recitations: Weds 7:00-9:00 or Fri 1:00-3:00

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

1.2 Readings

• Online Materials
  • Articles & manuals on internet
  • Book chapters
    • Available online via ODU library
    • Links within course website

1.3 Assignments

• Individual assignments
• Team Project

1.3.1 Project

A moderately large program on which you will work in teams of 4-5 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.

1.3.2 Project teams

• Teams for the first phase will be assigned randomly.

• You will choose your own teams for the remaining phases

  • Must be members of your recitation section.

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

• At end of each review meeting, you may receive a short test/assignment, which each team member must complete individually within a limited time period (a day or less).

1.4 Exams

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

2 Course Pre-requisites

3.1 Office Hours

Office hours are posted online

3.2 Course Forums

• the Hallway
  • for general discussion of course topics
    • no discussion of assignment solutions!
• the Janitor’s Closet
  • reports of site issues, broken links, missing or incorrect web pages, etc.

4 Important Policies

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

4.2 Academic Honesty

ODU is governed by a student honor code.

• Everything you turn in for grading must be your own work.
• 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.

4.3 Grading

5 Course Themes

Questions

• What is “Software Engineering”?

  • What is “Engineering”?

  • Is there “engineering” in software development?

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

5.2 Areas of Emphasis

• Test-Driven Development

• Build Management

• Version control

• Configuration Management

• Documentation Management

5.2.1 Test-Driven development

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

5.2.2 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

5.2.3 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

5.2.4 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?

5.2.5 Documentation management

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