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:
- be self-sufficient
- work in a team (communication, tools, etc...)
- organize and design software
- cope with a constantly moving target
- test and build robust code
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:
-
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.
-
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.
-
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.