I took this course for breadth, as I had no SWE training or experience, and had heard good things about this course from friends. This class is called "Software Analysis" (not really "Software Analysis and Testing"), and I didn't really know what to expect going into it.
Content
Software Analysis is about...analyzing software. Therefore, it's not just about "how to write tests for software" - it's about all kinds of different ways you can analyze software, and what the results of the analysis can tell you (soundness vs. completeness/false positives vs. false negatives).
The content is frequently abstract, math-y, and theoretical, although there are examples here or there about how useful some of the techniques are. I found the explanations to be clear and thorough, although not necessarily engaging. I didn't expect the content to be as abstract as it was, but now that I know more about the topic, I think that's appropriate.
The lectures were a little long but not oppressively. They're all on Udacity. There were generally several little quizzes sprinkled throughout each lecture that I found helpful.
Projects
There are 7/8 projects (there was a "project 0" - depends on if you count it). The first 3/4 projects are the hardest - 0-2 are hard because of LLVM and C, and 3 is hard because of Datalog. The rest of them take far less time (but it can be harder to get that "warm fuzzy clarity" that you get when you know that you have completely satisfied the project requirements).
All the projects had accompanying walkthrough videos that were remarkably brief despite covering all the requirements. Unlike some classes, the walkthroughs do not explain anything about how to do the projects - these walkthroughs are about getting you situated so that you know what is expected of you and where your work will take place. Some walkthroughs have small tips to help you find success, but these walkthroughs (like this class) are not there to hold your hand.
- 0. This was an introduction to LLVM and doing basic tasks with it. It took me a very long time - I think some of the earlier reviews from this semester for this course came from students that got overwhelmed by this project and the other LLVM projects and dropped the course.
- 1. This was a Fuzzing lab that used LLVM. Also difficult. Part 1 was hard because of LLVM. Part 2 was a puzzle - you're given binaries to simple programs that crash on certain kinds of input, and your task is to come up with a way of throwing randomly changing input at them in such a way that they'll crash (without knowing anything about how they work - hey, that's black box testing!). There was also a significant extra credit opportunity available (I wasn't able to take advantage of it - too busy - but it looked like it was interesting.)
- 2. This was a Dataflow lab that used LLVM. What is dataflow? There's a long lecture on it...but it's basically a kind of static analysis that works through each line of instructions to look for things like whether a variable is ever used before it gets redefined again.
- 3. Datalog...this was one of those projects where you could easily spend 20 hours on writing 5 lines of code. Set theory helps with this one, but I lost some points on it.
- 4. Type systems. This was in Typescript - fun little project where you slowly added type annotations to a big Javascript library to reveal where the bug was. Of all the projects, this one was the least related to the lectures, IMHO.
- 5. Cooperative Bug Isolation. Fun little exercise where you took the results of lots of crash reports to help you find the line(s) of code that were causing crashes. This one also had peer review.
- 6. Delta Debugging. This was a somewhat more challenging exercise where you took a large text input that caused a crash in a program, and whittled it down to a much smaller and more useful text input that exposed the same bug.
- 7. KLEE. I didn't do well with this one, but it's a way of adding instructions to obfuscated code to help reveal its "interesting" behavior. Lots of cybersecurity analysis implications, and another demonstration of how LLVM is useful (although you aren't directly interacting with LLVM in this project).
Some of these projects had "gotchas" that made it tough to get full credit, but it was straightforward to get a reasonable score. The rubrics were also clear and fair.
It seems like they are pretty good about thoughtfully designing projects and making adjustments based on the learning objectives and class experience/feedback. Projects 0 and 1 were new this semester, and were introduced to help students get comfortable with LLVM (and it sounds like more of the projects are slowly moving to LLVM), because LLVM and C had been large pain points for students on one of the other projects. I think it worked - while I still struggled with the other LLVM projects, they weren't nearly as hard as they would have been.
A special note on LLVM...it's a powerful tool, but it's used as a compiler. That means if you aren't comfortable with compilers + not comfortable with C + not accustomed to looking up documentation on an unfamiliar API = a rough time. Why would a compiler be applicable to this class? I saw some complaints about this. To me, it makes sense - a whole host of kinds of software analysis are white-box and static. LLVM lets you do things like change all " < " comparisons to " != " comparisons in a program, or flag all the places in a program where a variable is assigned a new value. So you aren't actually doing compiler kinds of tasks (like you don't need to know how to do optimizations, for instance), but there's a reason why it's part of so many projects in the class.
Pace of the course/Workload
I found the overall pace of the course to be busier in the first half of the semester, lighter in the second half. Part of this is because the harder projects are in the first half of the semester, and some of the harder lectures (like Dataflow analysis and pointer analysis) are in the first half.
However, all the projects were released at the start of the semester, so you also have the opportunity to work ahead if you want.
I think I spent about 15-20hrs a week on this class in the first half of the semester, and 10-15 hours a week in the second half.
Exams
The exams are tough, long, but fair. I would say they rival GIOS in this way.
Each exam has a set of practice questions and solutions that are very indicative of the rigor of the actual test. The instructors provided videos explaining how to approach most of the questions, sometimes with extra conversation of ways to think about the questions or tips for solving the more easily.
The exams are open lecture (you can have the pdf transcript of the lecture, which they provide, as long as the only edits you make to it are highlights), and you are allowed a single digital cheat sheet (they give you a template).
The exams are tough because the questions require you to be able to demonstrate that you can apply algorithms and analysis to a new problem. Rote memorization will not get you through these tests with success - you have to spend time understanding the material. That also means that cramming for these exams is difficult. Unlike classes with lightweight, multiple choice questions (like CN, ML4T, and IIS), a quick cramming of all the lecture videos won't be enough to get you a passing score (most likely). The practice questions (which they make available from the very start of the semester) are very good indicators of how well you need to understand a concept in order to succeed when tested on it.
I think the exams were fair because none of the questions felt like trick questions, and I felt like the practice exams that they provided ahead of time were sufficient to demonstrate how the test would flow. It was also clear to see how each question corresponded with the core of a lesson from lecture - none of the questions felt like they were just trivia questions to me (and even if they were, you had the full transcript of the lectures to ctrl+F through to find the answer if you wanted).
The exams were kind of long, but not much longer than the practice exams (just a little). Hard to know exactly how many questions there were on each exam (some questions were just "scratch space", and other questions were multi-part). As some students have mentioned, it was tricky to scroll around from a question to the scratch space, and copy-paste is disabled. However, as explanations from Chris Poch will tell you, that's not a hindrance that the instructor/TA team are trying to put in your way - some students from my class submitted proposals to Canvas to make the scratch space a "pop out window" to make the user experience, and Chris voted for it. This seems like it's one of those annoying but "no better solution exists" scenarios. That said, I took the exams on my little surface pro 3 tablet, and for the most part I felt like either the scratch space was reasonably "close enough" to the question, and/or the question had a way for you to work it out as you went along. I think practicing with these limitations on the practice exam go a long ways here.
The exam windows were three hours long. I think that's plenty of time - I had no issues with the time limit, and I didn't hear of anyone running out of time.
The final exam was not cumulative.
A logistical challenge - based on some unfortunate past experiences the instructor team has had, there are a LOT of instructions on the logistics for the exam. They have an exacting description + video of what they want to see with the room scan. There's a lot of instructions on how to do the cheat sheet + lecture transcripts. There's a policies acknowledgement quiz that's important. Make sure you leave yourself enough time to do a final check on whether you're doing all the logistics correctly.
TAs and Instructors
There are two instructors and a squadron of TAs. It sounds like this course isn't taught on campus these days and is completely online. This leads to a unique situation where one of the instructors and both Head TAs are OMSCS alums, and all the rest of the TAs are either OMSCS alums or OMSCS students themselves - there aren't any on-campus TAs. I think this is a benefit because on-campus TAs sometimes have a hard time understanding the challenges that come with being online only - this TA team is fully sympathetic and acts accordingly. I was also impressed by the wide array of experience that these TAs had based on their introductions from week 1. If you desire to (I didn't), they seem knowledgeable and willing enough to dialogue on where the course content intersects with the real world in their experience.
Mayur Naik is the creator and the PhD/professor backing the whole course - I didn't see much from him, but it seems like he is involved in the background, and he recorded some Youtube videos to walkthrough some of the final exam practice questions that were uploaded in March 2020, so that tells me he's very much there.
Chris Poch is the other instructor, and is much more involved in the administration of the course. He was on both Piazza and the course's Slack regularly. Since he is actually an instructor and not just a TA, he has much more authority than normal Head TAs do. That's significant because it means you can directly interact with him to request extensions, ask for a ruling on an issue, etc. - he has the authority to make policy decisions. Ultimately, that means a faster decision time, and also you can get more behind-the-scenes information on things like, "why is this taking so long to grade?" or other policy questions. He also clearly cares about communicating expectations clearly and making changes or policies that are beneficial to the students. (For instance, he explains that they push to get grades back rapidly because studies show students learn best when they receive prompt feedback.)
I found all the TAs to be knowledgeable, helpful, and respectful. Naturally, some were more helpful than others, but I had no complaints with any of them. However, "helpful" != "holding a student's hand or giving away the answer." They are more likely to help you reach understanding via the Socratic method (in other words, by asking you questions back), than they are to drop hints.
The TAs and Chris held a consistent schedule of office hours via the CS 6340 Slack workspace in a dedicated channel. I only used the OH once, but I saw them actively helping students throughout the semester. There was generally at least one OH session per day, with some days having more than one session, and there were generally extra OH sessions on the weekends. The OHs were pretty much for helping students with projects, and like 90% of the time they involved one-on-one DMs with students.
This is not a team that will get "buddy buddy" with you (like IIS) - the team is very professional. However, that doesn't mean that they aren't encouraging or helpful.
Piazza and Slack
This course uses both Piazza and Slack. For Piazza, it got extra messy this semester as they instituted participation credit (and extra credit) for the first time. It seems like they applied the credit fairly, but I won't say much about it because I'm really sure they're going to be tweaking how it's done. They set up Piazza to have folders and instructor posts in the usual way - I didn't have too many problems navigating it. However, because nearly all the projects are released at the very start of the semester, you can have some people working on project 1 and some working on project 7 (we had a handful of students who finished all the projects before the midterm). I found that just passively marking posts to future projects as "favorites" to find them when I needed them later was useful.
The Slack workspace is not as casually active as others (GIOS and IIS workspaces are much more active), but there was reasonable student interaction. The office hours channel was busy consistently. I found it useful to just passivly check Slack here or there as students normally would chatter there if another student had uploaded a test suite that I didn't already know about.
Special note: COVID 19 response
Chris made special accommodations/announcements early (about as quickly as Dr. Joyner did in his classes). They had a system in place quickly to grant students up to one week extensions on any project, and for students to request incomplete grades if needed. He also provided a lot of information on the ramifications for taking an incomplete, and I had a few friends that ended up doing that. It sounds like Chris took good care of anyone who had extenuating circumstances.
They also pushed and opened the final exam almost a month early so that students could have a longer window. (for perspective, the midterm was only open for about 3-4 days) Chris was super open about how that added a lot of big questions for some policies (for instance, they had to cut the participation grade short because students that took the exam weren't allowed to participate in any conversations concerning open labs).
My overall sense of the situation was that they worked hard to be accommodating and understanding to students while still ensuring that they had reasonable requirements for students.
Summary
Overall, I thought this was a very well executed course. I can't speak for how applicable all the concepts are to real world work (no experience in it). I am glad I took the class, although I've decided that the topic is not one I'm interested in. Nevertheless, I learned a lot, and I'm confident I'll see some of the concepts again in other areas. I think it's very doable to earn a satisfactory grade, and that this isn't a class where one mistake costs you a letter grade (I mean, unless you do something like completely disregarding the room scan on an exam). This class is a good class to take solo or paired with a lightweight second class (I paired it with ML4T). I'm sure that there's room for improvement in how this course is delivered, but I had a positive experience. I think most people who had negative experiences had different expectations for what this class is. Just make sure that you have appropriate expectations walking into it, and I think this class is beneficial to any OMSCS student considering taking it.