17-654/17-754 Analysis of Software Artifacts Course Policies
Overview
The goal of this course is to communicate how analysis techniques can
be applied throughout the software lifecycle to increase the
effectiveness of software engineers. So that students can better
understand how to reason about programs and the benefits and
limitations of various analysis techniques, the course will broadly
cover analysis theory including hoare logic,
dataflow analysis theory, model checking,
abstraction, and techniques for showing that abstractions are
sound. The course will cover analysis techniques that can be used
across the software lifecycle, including model checking of designs,
code reviews, code verification and bug-finding, and analysis
techniques for effective software evolution, maintenance, and
reengineering. Topics include not just analysis for correctness,
but also analysis techniques for quality attributes such as security,
reliability, performance (including real-time), memory usage, and
evolvability. Students will become familiar with several analysis
tools developed in academia and industry, both through readings in the
research literature and practical experience trying out one or more
tools.
After completing this course, students will:
- know what kinds of analyses are available and how to use them
- understand their scope and power, when they can be applied and
what conclusions can be drawn from their results
- have a grasp of fundamental notions sufficient to evaluate new
kinds of analysis when they are developed
- have some experience selecting analyses for a real
piece of software, applying them and interpreting the results
- be able to measure the effectiveness of analysis and manage an
analysis strategy in a project context
Prerequisites:
- Basis programming experience in a high-level language
- In particular, most assignments will require the use of Java, so students without Java
experience should expect to invest some additional time. While
the lessons of the course are largely language-independent, to make
them concrete they must be studied in the context of some particular
language. No language is ideal for every student, but Java was
chosen because it is one of the most widely known languages among our
students, because it has good object-oriented support for the OO design
analysis aspects of the course, because there are good educational
tools available, and because its popularity
in industry makes it a valuable job skill.
- An undergraduate-equivalent background in discrete mathematics,
as provided by 21-228, 15-251, or Models of Software Systems
(17-651/17-751)
This course fulfills the Analysis STAR requirement for the Software
Engineering Ph.D. program.
Evaluation
Evaluation will be based on the following approximate percentages:
- 65% assignments and projects
- 30% midterm and final exam
- 5% participation
Time Management
This is a 12-unit course, and it is my intention to manage it so that
you spend close to 12 hours a week on the course, on average. In
general, 3 hours/week will be spent in class and 9 hours on on readings
and assignments. To give me feedback on how much time the course
is taking, I ask that you keep track of the number of hours spent on
each assignment and report the time when you turn in the assignment
(many of the MSE students are doing this in any case, so it should be
little additional work).
Late Work Policy
Each student has 5 late days for the semester which can be used in any
assignment, so long as the assignment hand-in is not on the critical
path for the following assignment. When turning in your work,
just let the instructor or
TA know how many late days you are using. Work turned in late
after the late days are used up will only be accepted under
extraordinary circumstances.
Collaboration Policy
You may discuss any of the readings or assignments with your
classmates. You may also help each other with technical problems,
for example, with getting course software to run, answering questions
about how course software works, debugging an assignment, or getting
notation right. If any of this means looking at another student's
solution, the expectation is that you will already have done that part
of the assignment--but it is preferable to discuss the problems in the
abstract rather than in the context of a specific solution.
However, your assignment writeup or coding must be your own work.
Thus, you may not copy any part of a solution to a problem that was
written by another student, or was developed together with another
student. Nor may you look at another student's solution as you
develop your own. If you have worked together on something, you
must throw away your notes and re-develop the solution yourself, so you
are confident it is your own work. For example, you may work on
the homework with another student, but then you must erase the
whiteboard, go home, and write up your solution individually. Or, if
you discuss a problem with another student by e-mail, you must wait a
few hours and then write up your solution without looking at the
e-mail. We take your ability to independently recreate the solution as
proof that you understand the work that you submit.
Some assignments are specifically noted as group projects. For
these, interpret "you" in the preceeding paragraphs to mean "you and
your partner(s)."
If your completed assignment contains any statement that was not
written by you, you must put it in quotes and cite the source. If you
are paraphrasing an idea you read elsewhere, you must acknowledge the
source. Using exisitng material without proper citation is
plagiarism, a form of cheating.
Any violation of this policy
is cheating. The minimum penalty for cheating (including
plagiarism) will be a zero
grade for the whole assignment. Cheating incidents will also be
reported through University channels, with possible additional
disciplinary action. For more information, see the University
Policy on Academic Integrity and Plagiarism.
If you have any question about how this policy
applies in a particular situation, ask the instructor or TAs for
clarification.