17-654/17-754 Course Policies

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 program semantics, hoare logic, dataflow analysis theory, temporal logic and 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 and writing 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
An undergraduate-equivalent background in discrete mathematics, as provided by 21-228, 15-251, or Models (17-6XX/17-7XX)

This course fulfills the Analysis STAR requirement for the Software Engineering Ph.D. program.

Evaluation

Evaluation will be based on the following approximate percentages:

45% assignments
20% projects
30% midterm and final exam
5% participation and readings

The assignments will include:

Questions covering the theory of various analysis technologies, as well as their benefits and limitations in concrete engineering settings (exams will cover similar material in an evaluative setting)
Writing simple analyses and applying them to verify engineering properties of code

The projects will include

Applying commercial and research analysis tools to software artifacts and reporting on the results (in writing and with an in-class presentation)
Developing a quality assurance plan for a studio, practicum, or other project

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