Plans for a graduate-level course in Software Engineering that I will not be teaching

Several weeks ago, I was assigned to teach my department's graduate level Software Engineering course in the Spring. This is a bit of irony, since I agree with Alistair Cockburn that "software engineering" is a bad metaphor for what we do, as he explains in his classic book. Be that as it may, I was asked to teach the course, so I did what any honest professor would do and start preparing it as well as I can. Indeed, I even started setting up a community-engaged project based on some of the work that my students are doing now in my HCI class. Last week, however, I found out that there was only one student enrolled in the section, and the department decided to make some other kind of arrangement for that student. It's still not clear to me what I will be doing instead in the Spring, although it looks like I may pick up a section of HCI. I had already done a bit of planning, including reaching out to several alumni about their experiences in industry. Rather than let this languish in a few documents in my planning folders, I decided to compile a few of my notes here.

The SE course master syllabus is not very well constructed, which is amenable to my desire to take an agile approach rather than the clearly-presumed waterfall approach. The master syllabus only identifies one course objective: "The student will be able to carry out a reasonably sized software project from requirements specification through analysis, design, implementation and testing." On reading this, my imagination turned to all the interesting things we could do to lead to this outcome. Further down, however, I came across the "Course Content" section, which comprises the following paragraph:

Topics include an introduction to software engineering, the software life cycle, user requirements, structured specifications, risk analysis, system design, module development, testing methodologies, software metrics and models, software cost and effort estimation models, validation and verification of software, software quality assurance and software reliability.

This gets to sound more like the table of contents of a textbook rather than being about concepts of effective software development. What I decided to do was to map out the content listed in that paragraph into the kinds of activities that I hoped to do, both to make a skeletal course plan and to find the holes that needed filling. Below are essentially my planning notes that I had up to last week, with just a little bit of extra context given to the reader who is not already in my head.

• Software lifecycle: 
• Contrast waterfall, spiral, and agile approaches
• User requirements:
• Requirements capture via CRC cards
• User stories, including Mike Cohn's format, Allen Holub's more narrative approach
• Potentially Jeff Patton Story Maps, although maybe this is more appropriate for the follow-up course on requirements and design.
• Structured specification
• Conditions of Satisfaction and Acceptance Criteria as part of Agile planning
• Behavior-Driven Development (BDD), as related to Test-Driven Development (TDD)
• Risk analysis
• Risk matrices from Microsoft Solutions Framework
• System design
• Robert Martin's Clean Code, SOLID, and Clean Architecture
• Potentially Allen Holub's Design by Coding concept
• Module development
• Clean Architecture and SOLID
• Testing methodologies
• BDD & TDD
• Integration testing / Continuous integration, potentially with jenkins or TravisCI
• Acceptance testing and Usability testing, using Nielson's Five Users heuristic
• Software Metrics and Models
• Chapter 14 of Clean Architecture includes fan-in, fan-out, and instability metrics, as well as an abstraction metric.
• Include some coverage of common UML notations, perhaps using Holub's UML Quick Reference and some work with UMLet.
• Software cost and effort estimation models
• Discussion of the #NoEstimates movement, including Holub's overview
• PERT Analysis with wideband Delphi (Clean Coder chapter 10)
• From here, estimate costs for a project using a helpful heuristic from a friendly alumnus: $75/hr junior developer, $125/hr senior developer, $150/hr architect, +20% for design work.
• Another friendly alumnus told me about at his company, contract costs were more art than science, built from years of experience and reflection rather than formal models. This is also valuable to know!
• Planning Poker
• Validation and Verification
• TDD / BDD / CI
• Code Review, perhaps using the SmartBear book
• Software quality assurance
• Contrast separate QA teams and cross-functional agile teams
• Software reliability
• Pair programming
• Code review
• Code standards
• Automated style checkers

Writing it all out, it sounds like kind of a good course, doesn't it? Imagine exploring these ideas embedded in a community-connected project, getting feedback from people outside the class, discussing models and philosophies of development. I was actually getting kind of excited about it, even though at first I was taken aback. Well, at least the notes are here, and perhaps someone will find them of value in the future. Thanks again to those friendly alumni who pointed me in some useful directions for some of the areas here that I was unsure about, particularly cost estimation.