This page contains the syllabus for CS 169 – Software Engineering.
|
|
Name |
Office |
Phone |
Email |
Office
Hours |
|
Instructor |
Eric Brewer |
623 Soda |
642-8143 |
TBA |
|
|
G.S.I. |
RJ Honicky |
|
honicky@cs |
TBA |
|
|
G.S.I. |
Bonnie Kirkpatrick |
|
|
TBA |
|
Lectures |
1 |
Tu/Th 1-2:30 |
306 Soda |
|
Discussion Sections |
101 |
W
8-9am |
75 Evans |
|
102 |
F 8-9am |
75 Evans |
Building
large software systems is hard,
but experience shows that building large software systems that actually
work is
even harder. And trying to do all this before your competitors has
proved fatal
to many software projects. This course covers techniques for dealing
with the
complexity of software systems. We
will focus on the technology of software engineering for the individual
and
small team, rather than business or management issues.
Topics will include, among others,
specifications, principles of design and software architecture,
testing,
debugging, static analysis, and version control. Students
gain hands-on experience
through a large course project, done in a team of 5-7 students.
CS61A-C.
It is very helpful if you have been already involved in a medium sized
software
project, perhaps a semester project in one of the project classes
(CS162,
CS164, or CS186).
There
is no required textbook for this class. Instead I will assign readings
from
research papers. I also recommend a few textbooks if you want to read
more
about the topics covered in class.
|
Recommended: |
“Software Engineering. A
Practitioner’s Approach”, by Roger Pressman |
|
“Code Complete”, by Steve
McConnell |
|
|
“Extreme Software
Engineering. A Hands-On Approach”, by
Daniel H. Steinberg, Daniel W. Palmer |
Copies
of the lecture notes will be made available on the course home page.
There
will be a number (up to 5) of
assignments in which you will be guided in the use of standard tools
for
software engineering: debuggers, automated testing tools, version
control, and
bug finding tools.
The
major component of the course will
be the course project. The project is split into several components. In
the
first component, you will have to write a short proposal for a project
topic,
in which you argue the usefulness and feasibility of the project.
Ideally, you
should propose a project for which you have a customer (friends,
family,
business entities, your pet, etc.). The course staff will then pick a
number of
the projects and you will have a chance to express your preference for
what
project you want to work on. We will assign people to projects based on
their
preferences and based on their declared expertise (or lack thereof). In
the
remaining stages we will walk you through collecting requirements,
design,
coding, testing. The design will be reviewed by one other team, and
each team
will also act as external tester for some other team. During the
semester
members of the group will have to give short updates on the state of
the
project, in lecture. These presentations will have a relatively low
weight in
the final grade. The main reason to have them is to allow the students
in the
class to learn from each other experiences. At the end of the semester
there
will be a demo session.
The
project is 50% of the grade:
documents related to each stage roughly 20%, final demo 20%, and
presentations
10%. The project grade will be adjusted by team review of each team
member at
the end of the semester.
You will lose 0.5% of the score for an
assignment, for each hour it is late.
There
will be one midterm examination (in class). There will be no final
exam.
Instead, each project team will have to given an oral presentation and
a demo
about the project.
Regrade
requests will only be
accepted for
programming assignments and exams. In either case, all regrade requests
must be
received within one week
upon receiving your score. For exams, we will only consider regrades if
we made
a mistake in the grading of your exam. For programming assignments, we
will
only consider regrades if we made a mistake in the grading of your
project or
if there was a small bug in your project that caused you to lose at
least 10
points. A small bug is one that can be fixed by changing very few lines
of code
without affecting the design or the algorithm in a significant way. All
such
requests must be made to your TA (not to the readers).
Students
are expected to attend
discussion
sections. Some relevant material, especially the details of the
programming
assignments and software tools, will be covered only in discussion
sections.
It
is impossible to pass the
course without
doing the project. The relative weight of the components of your grade
will be
approximately:
|
Homework
assignments |
20% |
|
Midterm
exam |
30% |
|
Project |
50% |
Handouts will be available on-line on the class home page.