Software Engineering

Last updated: January 24, 2005

Spring 2005
Class times: Tuesday and Thursday: 1:30-3:15pm HRN 235
Lab times: Friday 3:10pm-5:00pm HRN 535
Office hours: Any time I'm around or by appointment.

Instructor: Terence Parr
Teaching Assistant: Marc Greenberg

Abstract

There is more to being a professional developer than learning the syntax and libraries of a programming language--that part is easy. To become a seasoned developer, you must learn how to: These general concepts and principles can only be taught in an apprenticeship-like manner and with a good deal of self-motivation.

Besides this abstract knowledge, you must learn how the network, computer, operating system, and your software operate as a unit to provide a useful service. To do this, you must acquire skills traditionally associated with system hardware and software administration. This class provides a survey of real-world programming mechanics and introduces you to the latest object-oriented software development strategies.

Your class grade will mirror how I would evaluate you as a young developer while you develop a large piece of software: a bug tracking system.

Syllabus

We will cover the following topics in lecture:

Intro
Is there a problem in the software industry?
Compiling, Executing, and Jar'ing Java Code
Perforce Revision Control
Building Unit Tests With jUnit
Java Threads
Sockets
Databases & Java
Java Servlets
Intelligent Page Generation
Cookies
Sessions
E-Mail Internet Protocols
ACM QUEUE: How Not to Write FORTRAN in Any Language
ACM QUEUE: Languages, Levels, Libraries, and Longevity
The Essentials of Debugging
Object-oriented programming principles
The Relationship between C Structures and Java Classes
Top-Down Design In An Object-Oriented World
UML Diagrams
Software Patterns
Programming by contract
Mythical Man Month
Extreme Programming
Code Refactoring
Writing Flexible Code
jGuru System Case Study

Labs

Perforce
Sockets
StringTemplate

Mini-projects

Expression Evaluator
Expression Evaluator part II

Semester Project

Bug Tracking System
You will build a web-based bug tracking system in Java this semester as soon as I think you have the necessary technology. The project is to be completed by the end of the class. The labs in the early part of the semester will prepare you. You will work individually on this project. Your team will have to make their own decisions about functionality and development.

This course will emphasize real-world coding as if you were an employee of a software development company. As a result, you will note the following requirements that are unusual for a course:
  1. You will have to release and demonstrate your project on a regular basis (probably every 2 weeks) during the semester. At each release, you must have a working server. "Almost working" does not count. Imagine that you are building a site that users will begin to access immediately--you cannot release anything in a buggy or "almost-working" state. Show the working server from the last release rather than a new one that introduces bugs in the old functionality or that doesn't work. You can decide on partial functionality but not a partially implemented server. Every release must be tested and will optimally have new features even if the features are simplified versions. You will be graded on how many release dates you hit with new features.
  2. You will be given more work than can possibly be done in the allocated time period. You will need to prioritize the tasks and then decide which you will do, which you will simplify, and which you will not do. You may suggest alternative features or modified features. You may suggest that the instructor is nuts and a feature cannot be implemented. Your project management skills will be evaluated in this manner and will affect your grade.
  3. You may discuss the project but you may not share code. The other students are your "competitors" in the sense that your project is graded in comparison with the other teams to get beyond the B grade level into the A range.
In summary, we will simulate a piece of the real world: you have to constantly juggle releases with new coding, you always have too much to do, etc...

Submission
Any mini-projects will describe the submission process individually. The big project will be graded while you demonstrate your software in front of the instructor.

Grading
There are general definitions of C and B level work that must be completed to achieve those grades on the semester project. To get an A, you must impress me with your ability to code and do significant work beyond the B work in comparison to other projects. The author of the best project in the class will be excused from exam II. :)

By definition, there is no late project--your last working release will be considered in lieu of any unfinished project. Missing a release in order to achieve a better result at the next release is acceptable once or twice, but remember missing all releases to turn in a finished project at the end of the semester will yield a poor score.

Exams

There will be two exams: a midterm exam and a noncomprehensive final exam.

Instruction Format

Two class periods of 1hr 45min per week for 15 weeks. You are expected to sign up for one lab section also. I think everyone is signed up for the Friday 3:30 lab so far. Class will often be broken down into lecture followed by lab with a 10 minute break in between to service coffee and/or junk food requirements. Instructor-student interaction during lecture is encouraged and discussion groups will be formed to solve problems and debate programming philosophy. Many class periods will be devoted to tracking your class project.

As the instructor, I will act as project lead for each team. There is no substitute for being an apprentice to an experienced developer. This close interaction will teach principles that are difficult to convey in a lecture setting and will allow me to closely watch each student's progress/abilities.

Grading

Your grade will be computed according to the following weighted-average:
5%Class participation to include any graded labs and quizzes
10%Expression evaluator I
5%Expression evaluator II
25%Exam I
25%Exam II
30%Semester project

Please note that class participation is part of your grade. You must learn to interact with other developers and come up with solutions.

In general, I will read all papers, projects, quizzes etc... two times. Once to evaluate the average and a second time to assign scores. In the first pass, I also come up with a scoring strategy for each question.

I consider an "A" grade to be above and beyond what most students have achieved. A "B" grade is an average grade or what you could call "competence" in a business setting. A "C" grade means that you either did not or could not put forth the effort to achieve competence. An "F" grade implies you did very little work or had great difficulty with the class compared to other students.

De-merits

One of the most valuable lessons I can teach you is self-sufficiency, therefore, if you ask me a technology question that can be found quickly with google, you will receive a demerit. These will count strongly against your class participation score.

Questions about strategy and other abstract concepts are perfectly acceptable. Still, I will not do your thinking for you. You must try to code or figure out something, fail, and then ask me. Imagine bugging your boss or co-workers constantly about questions you could figure out yourself. You would quickly get the reputation of not knowing anything and would annoy your co-workers.

Resources

Books

There is no book for this class.

Development Environment

We will have free access to the excellent IDEA development environment from Intellij.

Revision Control

You will be using the Perforce revision control system for the team project.

CS342 Mailing List

I will be sending important information to this mailing list. You are required to sign up for this list. To sign up:

http://cs.usfca.edu/mailman/listinfo/cs342.

To share info or ask questions of your classmates, email cs342@cs.usfca.edu.

Miscellaneous

Tardiness. Do not be late!

Academic honesty. You must abide by the copyright laws of the United States and academic honesty policies of USF. You may borrow any code from the net that you may use according to its license, but you may not borrow code from other teams. All suspicious activity will be investigated and, if warranted, passed to the Dean of Sciences for action.