Software Engineering (CSE 503/Winter 2021)


Software engineering goes well beyond programming. It includes processes from defining a product to shipping and maintaining that product. Software engineering requires strong technical skills, but also strong teamwork and communication skills. Get ready to learn software engineering principles first hand, improve your technical skills, and ship a product.

Lecture

Staff

Communication


Syllabus

Course description

Software is becoming ever more complex and difficult to understand, at the same time as it is used ever more pervasively. It is hopeless to understand how software systems work (or why they do not work!) without automated assistance. Programmers need tool assistance during design, implementation, testing, debugging, and modification ("maintenance"). This graduate, paper-focused course will investigate a variety of program analysis techniques that address these software engineering tasks. Topics include static analysis (e.g., abstract interpretation), dynamic analysis (e.g., testing and debugging), and probabilistic methods. While the course focuses on the design and implementation of program analysis tools, the material will be useful to anyone who wishes to improve their reasoning about programs or get an overview of software engineering research.

Students will read classic and current technical papers and actively participate in discussions and a research project.

This is not a course about how to build programs, though the information in the class may help you to do that. Rather, this is a course about research in software engineering, and program analysis in particular.


Course format

All class meetings are virtual on Zoom. Classroom material is enhanced with assigned readings, in-class activities, and in-class exercises. Most class sessions will begin with a brief discussion and presentation of material, after (or during) which the floor will be open to rebuttals, discussion of related work, criticism, brainstorming about follow-on research, etc. We will all learn from the conversation, even the instructor. We will all have questions and confusions about the material, even the instructor. You are required to be not a passive listener to lectures but an active participant in the discussion.

Recordings

This course is scheduled to run synchronously at your scheduled class time via Zoom. These Zoom class sessions may be recorded. The recordings will capture the instructor's screen and the participants' audio. The recordings will not capture the participants' video. Likewise, the recordings will not capture group activities (e.g., breakout rooms). The recordings will only be accessible to students enrolled in the course to review materials. These recordings will not be shared with or made accessible to the public.

Paper readings

To help you prepare, you will write a one-paragraph commentary and answer readings questions for most papers, and submit your write up at least the day before the class meets to discuss the paper. You will post your commentary and answers to a Canvas discussion board for viewing by the instructor and by other students. The commentary should reflect your understanding and analysis of the issues raised by the paper, and should also help direct (both your and others') preparation for in-class discussion.

You may write the commentary in whatever style you prefer that meets the goals listed above. One good format for the commentary is to critique the paper, listing the following three points: its biggest contribution (and, briefly, why that result was not already obvious), its biggest mistake (in motivation, methodology, algorithm, data analysis, conclusions, or some other area), and the biggest question that it raises (or the most interesting and important follow-on work that it suggests). Another acceptable format is to summarize the paper, describing its thesis, approach, and conclusions, and stating why it is significant. The commentary should also list questions that you have about the paper, such as about technical points or connections to related work. For other ideas about how to critique a paper, see the following advice.

It's OK if you read the paper and there are issues you do not understand. Please ask questions about those issues -- both in your summary and in class -- and we will all gain by the discussion. It's best to explain why something makes no sense to you. For example, don't just say, "I didn't understand section 2", but state where there is a logical fallacy or a conclusion that does not follow or a term that is not defined. The instructor will use these questions to help shape the lectures.

You will have access to all the other students' write ups after posting your own. Please read them, which is a good way for you to get perspective. You can see what you missed (or what other people missed), and whether you agree with their take on the key ideas. It will help to make the class sessions more productive. We also encourage you to use the summaries to ask questions. If you have a question, it is likely that others have the same question but may be too shy (or vain, or insecure) to ask it; they will appreciate you raising the point.

Course project

The heart of this course is a team research project. Sample projects will be provided, but students are also free to propose their own, particularly ones motivated by their own problems experienced while programming. Examples include proposing and evaluating a fundamental new technique; developing and assessing new algorithms to replace currently-used ones; translating a methodology to a new problem domain; evaluation of proposed techniques (for instance, via a user study); and applying known techniques to new problem domains, such as operating systems, networks, embedded systems, security, biology, aerospace, etc.

You can find more details in the project summary.

Grading

Grades will be based on a research project, homeworks, and participation:


Course material