Software Engineering (Fall 2025)

CSS360: Software Engineering

Instructor: Kaylea Champion

Contact: I prefer, in this order:

1. public messages via Discord (others might have the same question or have the answer)
2. private messages via Discord
3. private messages via Canvas Note: all grade-related discussion must happen via Canvas
4. email only if absolutely necessary to kaylea@uw.edu

If you need to have a discussion with me, I would be happy to meet with you via an office hours appointment. This guarantees you my full attention (but, please book at least 24 hours in advance, I might miss your booking otherwise).

Turnaround time commitment

If I do not respond to your message in 48 hours, please understand that this is unintentional and nudge me via a Discord DM. My inbox and message queues sometimes get flooded due to a very wide range of commitments. This is not your fault, but an unfortunate fact of life. A polite and focused request will receive a faster reply; an unprofessional request might get eaten by my spam filter; a message containing information unrelated to your question might be misunderstood or misfiled.

You can call me "Doctor Champion" or "Professor Champion"! Please note that there is another Professor Champion in the department (Mia) and I am not her :-). I'm the one with the purple hair!

I use she/her pronouns, and I'll do my best to use your name and pronouns correctly, but please (please!) help me get it right if I'm wrong. Your comfort -- and your name and pronouns -- matter to me!

Textbook:

We do not have a required textbook. You will instead engage with material from a wide range of sources. All of these sources should be free of charge providing you use the version on Canvas or the UW Library Proxy. If you have difficulty accessing any material, let me know right away via a public message on Discord.

Course Meetings:

Tuesday / Thursday

3:30 PM to 5:30 PM

UW2 building room 131

Course Websites

• We will use Canvas for announcements and turning in assignments.
• We will use Discord for chat, including to ask questions and share information around the course material. (Invitation link is in the Class Setup Checklist.)
• Course absence form: It is important to tell me if you are not coming to class at least one hour before class begins.
• Everything else will be linked on this page.
• Got a question? Maybe it's on the UWB CSS 360 FAQs page?
• Optional! Pitch in to the Spotify playlist for this quarter's class. Share what's fun, what's cool, what's speaking to you this quarter, what more people should know about: the Software Engineering Fall 2025 Spotify Playlist. Otherwise we're just going to listen to things Prof. Champion picked ;).

Course Catalog Description of Topics:

Surveys the software engineering processes, tools, and techniques used in software development and quality assurance. Topics include life-cycle models, process modeling, requirements analysis and specification techniques, quality assurance techniques, verification and validation, testing, project planning, and management.

In addition, the course prerequisites amount to requiring completion of a two-course sequence in computer programming and serves as a prerequisite for CSS 370.

Overview and Learning Objectives

Software engineering is a collection of practices, philosophies, skills, and strategies for building and maintaining software.

As students of software engineering in the twenty-first century, I expect that many of you taking this course will, after graduation, work in jobs that involve the building and maintaining of technology, although your day to day activities may look as varied as stress-testing hardware to imagining new front-end interactions to reviewing piles of data to understand a system compromise to jumping out of bed in the middle of the night to fix an angry database. This class seeks to inform these experiences by helping you learn the engineering processes and practices in common use in a range of industries and settings, and how to think more broadly and more deeply about software work.

I will consider the course a complete success if every student is able to do all of these things at the end of the quarter:

• Write and speak fluently about key concepts in software engineering
• Recall, compare, and give examples of software engineering approaches that evidence suggests will be more or less successful
• Demonstrate an ability to critically apply ideas from the course to a demonstrator project.
• Engage with the course material and compellingly present your own ideas and reflections in writing and orally.
• Learn and use engineering tools, in part because the tools themselves are important, and in part to build your ability to adopt new tools.
• Identify areas of ethical concern in software engineering.
• Identify opportunities to improve software security in software engineering.

I also have a "stretch goal": I want your work in this class to help you, in some direct way. Maybe it's having a great answer in a job interview when it's time to convince the interviewer that you have a lot to offer. Maybe it's having a piece of work you can feel good about sharing with others. Maybe it's applying your CSS360 thinking to a new assignment at work. Maybe it's seeing your world in a new way that helps you solve a problem. Or maybe it's just having an answer when someone asks skeptical questions about what you got out of studying Software Engineering! This goal is hard to measure but it's my hope for you and what I'm working for every day during the quarter.

Class format and structure

In general, the organization of the course adopts a "flipped" approach where you engage with instructional materials on your own or in groups and we use synchronous meetings to answer questions, address challenges or concerns, work through solutions, and hold semi-structured discussions in the form of cases—discussed in detail below. This is a 5-credit class; you should plan to spend 10 hours per week working on class work as well as 4 hours per week in class and as much as 1 hour per week in lab or office hours. If you are spending substantially more than this, you should consider setting up an office hours appointment with me to think through learning strategies to boost your efficiency. If you are spending substantially less than this, you may find you are losing out on opportunities to learn, grow, and demonstrate your skills.

The asynchronous elements of this course include two parts:

1. All readings, recorded lectures/slides, tutorials, and assignments from a variety of speakers; some of these will be created directly by me, but some of them will be excellent work produced by others.
2. Conversation and discussion that happens in the group Discord server over the course of the week.

I expect you to finish all readings and watch all lectures outside of our class meeting times before the class sessions on which they are assigned. Please note that this means I will not generally deliver lectures during our class meetings. Please also note that this means you are fully responsible for reading all readings and watching all recorded lecture material before you come to the associated synchronous part of class.

I expect you to check in and participate in the Discord discussion. I plan to check and respond to conversation there at least daily throughout the quarter.

The synchronous elements of the course will be two weekly class meetings and optional open lab periods. Class meetings will happen at the normal time and in the normal place, unless I communicate otherwise. I will also offer open lab periods where you can drop in and ask questions. Open lab is an experiment I'm trying for this quarter to see if it's useful: I'll try to announce when they're coming up in a weekly announcement e-mail and I'll definitely mention them on Discord. For my more focused attention, please book an office hours appointment with me. Please note that if you book your appointment less than 24 hours in advance, I may not see your booking, so do ping me on Discord to confirm. Why should students book office hours appointments?

Each session is scheduled to run for a maximum of 120 minutes; we'll take a break half way through -- it's always my goal to end a bit early.

I will use the class meetings to do several things:

1. Conduct standup meetings for project teams.
2. Conduct each day's case study discussion involving an instructor-mediated conversation using input from each of you.
3. Discuss and work through any questions or challenges you encounter in the materials assigned for that day.
4. Discuss and/or answer questions about assignments that have come up.

Open lab periods will include:

1. Time for you to ask your questions
2. Time to work on your assignments with immediate help at hand

Attending open lab periods and office hours is optional.

Websites and Technology Expectations

There are a number of expectations that you will be able to connect to certain websites. In order to complete this class, I expect you to be able to access and use the following web resources:

• wiki.communitydata.science — This website will host the syllabus for the course. I expect you to be able to visit it regularly. If you're reading this, you have access.
• UW's Canvas — We'll be using Canvas for posting announcements, uploading course-restricted files, turning in assignments, and distributing grades, comments, and similar. It is the student's responsibility to verify that the correct file is submitted. If you have difficulties using Canvas, please contact UW-IT or see this knowledge base article.
• UW Library Proxy — I'm going to expect that you can use the UW Libraries proxy to access material that UW subscribes to from off campus.
• Discord — Discord is a chat system that we'll be using in the course to stay in touch between class and to discuss things asynchronously. It has screensharing and voice chat as well. There is a mobile app as well as a downloadable desktop app that you may find useful but you should be able to do everything you need to while using the web interface version. If you've got a question about an assignment, this is almost certainly going to be the the fastest and best way to get my attention. One benefit of asking a question on Discord is that others in the class will be able to see our answer to you! Instructions on joining the Discord server are in the Class Setup Checklist. You'll see that there are a series of channels we've created. If you don't see an obvious place to ask your question, go ahead and ask it in the #general-discussion channel.
• Panopto — UW uses the video hosting service Panopto which I will be using to share all the lectures and recorded parts for this course.
• GitHub — Assignments for this course will involve using GitHub. This means that you will need to have access to GitHub.
• Google Docs — I'll be using Google Docs to host a series of web forms. This includes the form you'll need to fill out to tell me that you're going to miss class. You will need to be able to access Google to use this.
• AI tools: Chat GPT, Microsoft CoPilot, and Gemini

These websites, in turn, use a range of hosting providers including Amazon Web Services, Google, and Microsoft. As a result, participation in this course requires students to access Internet resources that may not be accessible directly in some places outside of the UWB campus. Anybody taking the class must ensure that they can access all Internet resources required for this course reliably and safely. For students who are off-campus temporarily and are in a situation where direct access to these required resources is not possible, UW-IT recommends that students use the official UW VPN, called Husky OnNet VPN. UW-IT advises students to use the VPN with the “All Internet Traffic” option enabled (see the UW Libraries instructions and UW-IT’s FAQs). Doing so will route all incoming and outgoing Internet through UW servers while it is enabled.

Students who are outside the US should be aware that they may be subject to laws, policies and/or technological systems which restrict the use of any VPNs. UW does not guarantee students’ access to UW resources when students are off-campus, and students are responsible for their own compliance with all laws regarding the use of Husky OnNet and all other UW resources. You cannot successfully complete the course if you do not have sufficient access to a network and network-based services.

Having problems with the checklist? Running into terms you don't understand? I've collected some Frequently Asked Questions and Answers

Note about this Syllabus

You should expect this syllabus to be a dynamic document (not a 'contract'). Although the core expectations for this class are fixed, the details of projects, readings, and assignments will shift based on how the class goes, guest speakers that I arrange, my own readings in this area, etc. As a result, there are four important things to keep in mind:

• Although details on this syllabus will change, I will try to ensure that I never change readings more than six days before they are due. This means that if I don't fill in a reading marked "[To Be Decided]" six days before it's due, it is dropped. If I don't change something marked "[Tentative]" before the deadline, then it is assigned. This also means that if you plan to read more than six days ahead, contact me first.
• Because this syllabus is a wiki, you will be able to track every change by clicking the history button on this page when I make changes. I will summarize these changes in the weekly announcement on Canvas] sent that will be emailed to everybody in the class. Closely monitor your email or the announcements section on the course website on Canvas to make sure you don't miss these announcements.
• I will ask the class for voluntary anonymous feedback frequently — especially toward the beginning of the quarter. Please let me know what is working and what can be improved. In the past, I have made many adjustments to courses that I teach while the quarter progressed based on this feedback.
• Many readings are marked as "[Available through UW libraries]". Most of these will be accessible to anybody who connects from the UW network. This means that if you're on campus, it will likely work. Although you can go through the UW libraries website to get most of these, the easiest way to get things using the UW library proxy bookmarklet. This is a little button you can drag-and-drop onto your bookmarks toolbar on your browser. When you press the button, it will ask you to log in using your UW NetID and then will automatically send your traffic through UW libraries. You can also use the other tools on this UW libraries webpage.

Organization

This course addresses topics at macro, meso, and micro levels. We'll start broad, work our way down through middle layers to a detailed level, and finish the quarter by stepping back up to a macro layer again. My style of teaching is to infuse historical perspectives, current research, security, and ethics into each topic, although the total clock-time of each of these elements will vary.

Theme 1: Macro

• Software Development Lifecycle
• Collecting and Evaluating Evidence
• Systems, Infrastructures, and Supply Chains

Theme 2: Meso

• Patterns for Organizing Work
• Patterns for Design and Architecture

Theme 3: Micro

• Metrics
• Tools
• Tactics

Assignments

The assignments in this class are designed to give you an opportunity to try your hand at using the conceptual material taught in the class. We will do one project and have one short writing assignment reflecting on that project and course topics. Any quizzes will be short and low-stakes. There will be no exams.

Unless otherwise noted, all assignments are due at the end of the day (i.e., 11:59pm on the day they are listed as being due, Pacific time zone).

In Class: Discuss, Listen, Co-Work

Case discussion

The course relies heavily on the case study method: a particular form of instructor-mediated discussion. A standard "case" usually involves reading an example—perhaps up to 20-35 pages of background about an event and the surrounding context, or an organization or group facing an ambiguous or difficult challenge. I will mark certain readings as "[Cases]" in the syllabus and I will expect you to read these particularly closely. It is important to realize that I will not summarize case material in class and I will not cover it in lecture. I expect you all to have read it and we will jump in and start discussing it.

Cases ask students to put themselves in the positions of individuals facing difficult situations to tease out the tensions and forces at play in the case and to construct — through group discussion — the broader lessons and takeaways. Cases are a wonderful way to connect the sometimes abstract concepts taught in many academic courses to real examples of the type of ambiguous situations that you will likely encounter in your career. Generally speaking, there are not right and wrong answers in cases, but there are poorly-prepared answers versus carefully-considered ones!

Cold Calling

Cases rely roughly on the socratic method where instructors teaching cases cold call on students—i.e., instructors call on people without asking for volunteers first. I will be doing this in each class. Modern technical work environments include very similar situations: in a team meeting, participants are unlikely to raise their hands to answer broad questions! Instead, your manager and co-workers are likely to expect you to describe your own work as well as to respond to the scenario in front of the group in a well-prepared and focused way.

Because I understand that cold calling can be terrifying for some students, I will be circulating a list of questions (labeled "Reading Note" in the syllabus) that we will discuss alongside the weekly announcements (i.e., at least 6 days in advance). I will only cold call to ask questions for which you have time to prepare your answers, or where the general format / structure has been announced in advance so that you can prepare. Although it is a very good idea to write out answers to these questions in advance, I will not be collecting these answers. You are welcome to work with other students to brainstorm possible answers. Although I may also ask spontaneous questions that I do not distribute ahead of time, I will never cold call when asking these questions.

I have written a computer program that will generate a random list of students each day and I will use this list to randomly cold call students in the class. To try to maintain participation balance, the program will try to ensure that everybody is cold called a similar number of times during the quarter. Although there is always some chance that you will called upon next, you will become less likely to be called upon relative to your classmates each time you are called upon.

Assessment for case study discussion

I have placed detailed information on case study-based discussion on the case discussion section of my assessment page. This describes both the rubrics I will use to assess your case discussion and how I will compute the final grades in the course.

Sprint Planning Meetings

Once project groups are formed and we have covered the Agile approach, you will conduct sprint planning meetings. In sprint planning, you will examine the sprint backlog and available user stories, then commit to complete that user story during the sprint.

Standup Meetings

Once project groups are formed and we have covered the Agile approach, you will meet in a standup format at the beginning of each class. In standup, you answer three questions: what did you do since the last standup, what will you do before the next standup, and do you have any blockers? One member will take on the role of Scrum Master, a duty that will rotate among group members. All members will update the Kanban board and the Scrum Master will pursue removing any blockers and send me post-standup notes so that everyone gets credit for the standup. Your performance in standup will be assessed according to the rubric described in the detailed page on assessment

Out of Class: Read, Watch, Write, and Code

Each class session will require advance preparation from you, including engagement with class materials and working on course projects. More details on the class materials are in the daily schedule, and more details on course projects are in the assignments section.

Projects

You will participate in a group project to build a Discord bot as part of this class. The basic project is simple and straightforward, however students also have the option to propose their own bot project. Your ideas may be slightly different than what the course is structured to support. If you have a strong idea, proposing your project early will let us iterate on that proposal in sufficient time to allow timely completion.

The "SW Engineering Project Rubric" section of the detailed page on assessment gives the rubric I will use to evaluate these projects.

The "Writing Rubric" section of the detailed page on assessment gives the rubric I will use to evaluate writing assignments.

Notes on Group Work

Real-world software engineering is a team sport -- but in a school context it can be frustrating. The project in this course is designed to be lightweight: the purpose is to practice the processes we are learning about, which are mostly about working together to write code. That means facing the challenges of group work. To lighten the coding load, I encourage you to make substantial use of code assistant AI tools in a rapid prototyping mode: treat the AI tool as if it were your intern or a junior member of your team, give it assignments, assess its work.

Group process is key to this course. Think carefully about what kind of group member you want to be, and how you will respond to potential sources of conflict. In general, groups work well when students have motivations that align with the work of the group, varying skillsets, and display mutual respect. I will assess your work based on the evidence I see in behavioral traces: the records left behind in the tools we use for the course.

Building awareness of your own priorities and skills is crucial to being a good group member. I will be collecting confidential feedback on how groups are functioning, and I reserve the right to rearrange group membership to support everyone's learning.

Do you want an excellent grade in the course? Be clear about your expectations and priorities, and seek out groupmates who share your level of commitment.

Are your skills still emerging? Be ready to work hard, to learn from classmates, and to be flexible about which tasks you take on (but don't plan to coast on the efforts of others!).

Have you made life choices that mean you will need to simply be satisfied with an okay grade? Be transparent with your groupmates and only make commitments you can keep.

Although some developers work alone or nearly so, that is not the model for this course. Some of our learning goals require trying out ideas related to coordinating the work of groups of people.

Project: Developing a Discord Bot as a Team

Your team will develop, analyze, and deploy a Discord bot in ways that indicate your understanding of key course concepts. This overall project has been broken up into multiple tasks, each building on the previous.

Bot Project Task #1

Task

Set up your project environment

Due

Friday, October 3, 11:59 pm Pacific Time

Deliverables

You are done with task 1 if you have a GitHub project environment, a Discord test server for yourself, and a Discord deployment server set up for your group, with all group members and Dr. Champion able to access both the project environment and your group's deployment server. This is a <60 minute task; don't over-complicate it!

Turn In

A screenshot of your individual Discord test server, a screenshot of your Discord group deployment server, and a screenshot of your GitHub project environment.

Steps

1. Devise a team name. (in class)
2. Create a GitHub project environment (one per group) to match the name. Create a Kanban board to track your work; it's ok to just use the provided template. (in class) [Some screenshots of the process]
3. Create a Discord deployment server (one per group) (in class). [Some screenshots of the process] and Discord has a how-to page as well.
4. Create a Discord test server (one per student).
5. All group members and Dr. Champion need invites to and should join all group environments.
6. Ping Dr. Champion in Discord to tell her you're done. She does not want to install your bot, she only wants to be a member of your server!
7. Make sure Dr. Champion has the power to add user stories into your project Kanban board (you will need these for task 3 and beyond).

Tips

• Feel free to add customizations / tweak the icons (it will help you tell your environments apart from your classmates')
• Feel free to use AI tools as a tutor or source for debugging any issues that come up.

Bot Project Task #2

Task

Version 1.0 of your bot

Due

Friday, October 10, 11:59 p.m. Pacific time

Deliverables

You are done with task 2 if you have cloned your group repository from our class organization, deployed a working Discord bot in your individual test environment, and deployed a working Discord bot in your team's deployment environment ('working' in this case means, able to play the simple 7-option rock-paper-scissors style game described in the tutorial).

Turn In

Screenshots with a visible chat history which demonstrates that this is the case.

Steps

1. Follow the tutorial at https://discord.com/developers/docs/quick-start/getting-started closely -- with one exception: ignore the git command in the tutorial and instead Xxxxxxxx. This will mean you are working with the repository associated with your group and your work will be attributed to our class and your group correctly.
2. You will end up installing ngrok, npm, cloning the GitHub example, and establishing an identity with discord for your bot.

Tips

• If you get stuck, walk through the tutorial line by line: it's detailed, and it works, but there are some subtleties.
• I found it helpful to do this phase on a pair of large monitors so that I could have all my windows open side-by-side.
• Be very careful with the API tokens and secrets: do NOT exchange them via public channels, do NOT commit them into GitHub, and do NOT paste them into AI tools or search engines!
• Step 4 of the tutorial has you edit the sample project's code. If you get a 'didn't respond in time' error when testing your bot, perhaps it is because there's no response to the '/challenge' command in your project code?
• Remember that your team only needs one deployment environment (screenshot that it works).
• Feel free to use AI tools as a tutor or source for debugging any issues that come up.
• You should consider your fork to be a 'hard fork' -- that is, I do not expect (or want...) you to create a pull request merging your group's code into the class's default code. You will be taking a very basic shell and heading in your own independent direction from the starting point I provide.

Bot Project Task #3

Task

Version 1.1 of your bot

Due

Friday, October 17, 11:59 p.m. Pacific time

Deliverables

You are done with task 3 if you have each completed at least one of the user stories supplied by Dr. Champion for your first sprint and successfully deployed the updated bot to your deployment environment for Dr. Champion to review. Tag the code so that it is clear which version is 1.1.

Turn in

A screenshot of version 1.1 of your bot in action.

Steps

1. In sprint planning, assign one of the user stories written by Dr. Champion to each member of the group.
2. During the sprint, resolve that user story.
3. Commit often! Test often!
4. Open a pull request to merge your code into the team's main branch.
5. Review your pull requests for conflicts.
6. Merge code and tag a release when done with the sprint scope
7. Deploy your version 1.1 into the production environment

Tips

• The exact path your project takes will be different from other groups at this point. Be ready to sort through conflicts using your group chat or in standups!
• Our architecture means someone will need to be running the bot locally for it to be graded, so expect your group to get a ping on Discord to coordinate this.
• Feel free to use AI tools as a tutor, as a rapid prototyper, for code review, and as a source for debugging any issues that come up.

Bot Project Task #4

Task

Analyze the architecture of your assigned bot

Due

Friday, October 24, 11:59 p.m. Pacific time.

Deliverables

You are done with Task 4 if your group has written an architectural guide and added it to your main repository on GitHub. All group members should have made at least one substantive commit to the guide to receive credit and include a diagram explaining how pieces connect to one another.

Turn in

No need to turn in something for this; Dr. Champion should be able to grade your work right out of GitHub.

Steps

1. Think about the levels or facets of system architecture involved in your project.
2. Identify a layer or aspect for each group member to cover.
3. Be concise and accurate in your description and clear in your diagrams.

Tips

• Divide up the work so that everyone has a piece to contribute
• Include both system architecture and code architecture
• Consider different audiences: your future self, a curious customer for your bot, a future employer
• Feel free to use AI tools as a tutor or source for debugging any issues that come up, however you are responsible for the accuracy of the content.

Bot Project Task #5

Task

Identify bugs and technical debt in your assigned bot

Due

Friday, October 31, 11:59 p.m. Pacific time

Deliverables

You are done with Task 5 if you have conducted an analysis of limitations and weaknesses in your assigned bot by (1) publishing a report to the main repository and (2) creating user stories drawing from both the problems you've found and any new ideas for improving your bot that arise through this process.

Turn in

No artifact turn-in required, Professor Champion will grade the state of your repository and project board.

Steps

1. Divide up the different perspectives on code analysis into tasks for each group member, which might include...:
   1. Run XXXXXXXX on your code.
   2. Run XXXXXXX on your code.
   3. Examine your code for evidence of XXXXX from our reading XXXXX.
2. Describe your findings in a shared code analysis report in your repo.
3. Create user stories associated with your findings.

Tips

• Think about how your bot has been used so far. Did anyone try anything that didn't work or wasn't supported? Maybe that's a bug or feature request?
• Think like a bad actor: what happens if you try to break your bot?
• Feel free to use AI tools as a tutor or source for debugging any issues that come up, however you are responsible for the content you turn in.

Bot Project Task #6

Task

Release version 2.0

Due

November 21 (Friday), 11:59 p.m. Seattle time.

Deliverables

You are done with Task 6 if you have each completed at least one user story from your second sprint and deployed version 2 to your production environment for Professor Champion to review. Tag the code so that it is clear which version is 2.0.

Turn in

A screenshot of version 2.0 of your bot in action.

Steps

1. In sprint planning, assign a user story to each member of the group.
2. During the sprint, resolve that user story.
3. Commit often! Test often!
4. Open a pull request to merge your code into the team's main branch.
5. Review your pull requests for conflicts.
6. Merge code and tag a release when done with the sprint scope.
7. Deploy your version 2.0 into the production environment.

Tips

• As with v1.1, expect a ping on Discord for grading coordination.
• Feel free to use AI tools as a tutor or source for debugging any issues that come up.

Bot Project Task #7

Task

Release version 2.1

Due

Thursday, December 11, 11:59 p.m. Pacific Time (Note that this is AFTER the demo because you will be incorporating feedback from the demo.)

Deliverables

You are done with Task 7 if you have each completed at least one user story from your third sprint and deployed version 2.1 to your production environment for Professor Champion to review. Tag the code so that it is clear which version is 2.1.

Turn In

Screenshots of each new feature added for v2.1. (This is during Finals Week, so a live demo for grading is not possible)

Steps

1. In sprint planning, think about how your demonstration went and reflect on what refinements you'd like to make
2. Assign a user story to each group member.
3. Complete at least one user story.
4. Commit, test, merge as usual.
5. Tag a release as 2.1
6. Deploy version 2.1 and screenshot for turn-in purposes.

Tips

• Your group might want to submit this early to boost your finals week flexibility.
• Feel free to use AI tools as a tutor or source for debugging any issues that come up.

Demonstration of Bot 2.0

You will demonstrate version 2 of your bot to the class in two ways: a live demo and a pre-made demo, as follows.

Pre-made Demos

Task: Record a pre-made demo of your bot (about 2 minutes).

Due

Monday, November 24th, 11:59 p.m.

Deliverables

Each group member will record their own screencapture video of the bot in action with a voiceover.

Turn In

a video upload to canvas (one per student).

Live Demos

Task: Conduct a live demo of your bot

Due

In class on Tuesday, November 25th.

Deliverables

During your 5-minute slot, show off what your bot can do.

Turn In

no artifact -- just be present and prepared.

Steps

1. I'll determine an order for presentation; you'll determine how to present the work.
2. Slides are not necessary, but a view of your bot in action is.
3. To avoid awkwardness around switching laptops, my laptop will drive the projector. However, you will present from your own computer. To accomplish this, all presenting laptops will join a Zoom room and screenshare to present.

Tips

• In case of live demo failure, be prepared to share 2 of your pre-made demos as a fallback so that you can get good feedback.

Bot Feedback

Task: give feedback to each group

Due

Monday, December 1, 11:59 p.m.

Deliverables

a short paragraph of highly specific feedback; grading will be according to my detailed rubric for giving feedback in brief

Turn In

a text submission on Canvas

Tips

• If you're not sure what to write based on the demo you saw, take a look at the group's repository and offer feedback based on the code and documentation you see.
• The feedback should be your view and grounded in your observations: do not use AI tools for this assignment.

Reflection on Software Engineering and the Bot Project

See the brief reflection rubric for details on my expectations in terms of the content of the reflection. A successful essay will do the following things:

1. Use content and concepts from the course.
2. Use evidence from your experience and the bot project.
3. Cite your sources; these sources must be real, they must provide support for the statements associated with the citation, and they must be viewable by me. Note that AI tools are notorious for fabricating these and use of AI tools for this assignment is forbidden.
4. Be 800-1200 words. Under 800 is unlikely to achieve the depth I am seeking here, and over 1200 words is unfair to others.
5. Not use AI tools.

If you are not sure what to write, think about what happened in the project and choose some of these prompts as jumping off points (do not treat the following as questions to answer in order!). What kind of work did you end up doing, and how well did you do? Was the project easy or hard, which parts, how, and why? How did the analysis go, and what did you learn? Walk through each topic we covered. How did course concepts apply (or fail to apply) to the situations you faced in developing your bot? Did anything surprise you or change your mind during the project? Based on your experience, what is your advice for the students who take this course next? What did you learn about yourself and the ways you prefer to work?

Do not write in a long single paragraph or send me a list of bullets; instead, write a standard essay with an introduction, key points, and conclusion. Do not use AI tools. Do use examples and evidence. This should be an essay that only you could write, because it's about specific events in your experience of the course.

Turn in

a well-formatted essay via Canvas

Grading

I will follow the very detailed grading rubric described on my assessment page. Please read it carefully. I will assign grades for each of the following items on the UW 4.0 grade scale according to the weights below:

• In-class activities, including case discussion: 50%
• Sprint 1: 10%
• Sprint 2: 15%
• Sprint 3: 15%
• Presentation (Demo and Feedback): 5%
• Reflection: 5%

Impact of Missing Class If you must miss class, must be late, or must leave early, file the class absence form to alert me. Not filing this form ('no call, no show') will impact your in-class activities grade. Advance notice lets you avoid a penalty, but it does not serve as a makeup. There is no direct way to make up for missing in-class activities. Instead, you can expect to be called upon more often in subsequent classes to balance out your participation. Please note that if you miss too many classes, it will eventually become impossible to receive full credit for the in-class activities portion of the grade as I will not be cold calling the same person an excessive number of times in a single class session.

Grade Questions Everyone makes mistakes and I want to fix mine as quickly as possible. If you have questions about a grade, book a private timeslot on my calendar within 2 weeks of the grade being released. In a grade consultation session, I will ask you to take the lead: show me in specific detail how your work fulfills the rubric for the assignment type, how you fulfilled the criteria for the specific assignment, and how your work meets the learning goals of the course.

Mapping Percentage to the 4.0 Scale Instructors have discretion in how we make use of the 4.0 grading scale; we select the weight for each element of the course, the number of points available, and crucially, we decide how best to map a percentage of those points into the 4.0 system. This mapping, and the evenness of spacing within the mapping, may vary from class to class, and it may be quite different from what you are accustomed to seeing elsewhere at UWB (or feel unnatural, if you grew up as I did, receiving letter grades). For this quarter of this class, I will map an overall 97.0% to a 4.0 and a 60.0% to a 0.7, with even spacing in between. This means to receive a 2.0 for the course, you need a 74.6% in the class. Doing the bare minimum is a high-risk approach, and I don't recommend it. Instead, come to class prepared and do all the work on schedule.

Late Policy With respect to Bot Project 1-7, note that the assignments are due Fridays at 11:59 p.m. Pacific time. Among these 7 projects, you may choose one project for which you want to use one 48-hour extension per quarter, no questions asked. Use Canvas to make your request so that it is private and trackable. I suggest not using your extension unless you cannot avoid it (you might need it later!). Note that assignments in this class tend to build upon one another; being late with an assignment means less time to do the next stage. In addition, the group nature of the assignments means that if your work lands late, you may need to work harder to resolve code conflicts and coordination problems. You should not expect your groupmates to do extra work to accommodate your need for an extension.

No extension is possible for the Demo and Feedback assignments as those involve coordinating the entire class community and have very tight timing. No extension is possible for the Reflection assignment because it sits at the very end of the quarter and I must submit grades on time.

If you experience a severe or extraordinary interruption to your ability to complete class work in a timely manner, I expect to follow the UWB policy around incompletes and to work with you, the advising office, and the disability services office as required to navigate your difficult situation.

Schedule

Sprint Prep

September 25 (Thursday): Introduction to the Course, Software Engineering, and SDLC

Before Class

• Watch the 'Introduction to CSS 360' video.
• Read over the syllabus (this document!) and be ready to ask questions.

In-class Goals

• Review class structure and plan for the quarter
• Dive in on content: what is software engineering? What is the software development life cycle?
• Start the class checklist

Optional Materials

• Interested in how this broad idea of a Software Development Lifecycle then gets used to advance our thinking via research? Check out this poster example using a generic SDLC customized for research software as a way to organize our thinking about how to develop software for research: Yehudi Y, Cashman M, Felderer M, Goedicke M, Hasselbring W, Katz DS, et al. Towards Defining Lifecycles and Categories of Research Software. deRSE25 Conference Proceedings. 2025;doi:10.5281/zenodo.15002661. Poster Link
• Interested in how security gets integrated with the Software Development Lifecycle? Read: A. Wee, A. Kudriavtseva and O. Gadyatskaya, "“Have Heard of it”: A Study with Practitioners on Adoption of Secure Software Development Frameworks," 2024 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), Vienna, Austria, 2024, pp. 626-633, doi: 10.1109/EuroSPW61312.2024.00076. Paper Link

September 29 (Monday): DUE: Class Checklist

Required Task: Complete the class setup checklist. This will take as much as 90 minutes (and includes a tutorial on JavaScript) so please plan in advance.

As with most other assignments, you must complete this task by 11:59pm Seattle time.

September 30 (Tuesday): Organizing Patterns: Agile, Waterfall, and All That

Before Class:

• Read the Reading Note
• Watch the lecture video Organizing Patterns: Agile, Waterfall, and All That [45min]
• Read the Agile Manifesto and the 12 Principles.
• Read Chapter 1 from The Mythical Man Month

In-class Goals

• Class Discussion (see reading note)
• Group Discussion - Scenario matching (see reading note)
• Groups assigned and announced.
• Your first sprint planning meeting!

Optional Materials

• Interested in even more specifics about Agile and the methodology? IBM offers a Coursera Course on this topic called Introduction to Agile Development and Scrum.
• Interested in Conway's Law? Check out this blog post from Martin Fowler

Sprint 1

October 2 (Thursday): The Problem of Coordination (Git and GitHub)

Before Class

• Read Reading Note #2
• Read Chapter 2 of Mythical Man Month
• Read A very short history of Git
• Watch Video and Read Blog Post describing distinction between Git and GitHub [9m]
• Watch my lecture on How to Read a Software Engineering Research Paper
• Read this research paper: Helena Tendedez, Maria-Angela Ferrario, Jon Whittle. 2018. Software Development and CSCW: Standardization and Flexibility in Large-Scale Agile Development. In Proceedings of the ACM on Human-Computer Interaction, Vol. 2, CSCW, Article 171 (November 2018). ACM, New York, NY. 23 pages. Download Here

In Class Goals:

• Finish Reading Note 1 as needed
• Discuss Reading Note 2
• Finish Sprint Planning
• Standup
• Hands-on / triage issues with Task 1 (due tomorrow!)

Optional Materials

• Wikipedia entry on Git
• TED Interview with Linus Torvalds

October 3 (Friday)

Bot Project Task 1 due at 11:59 p.m. Pacific time. If you're done early, get started on Bot Project Task 2!

October 7 (Tuesday) Learning from Failures and Fiascos Part 1

Please be aware that these cases involve some visceral description, human tragedy, and loss of life. Although this material is disturbing, I include it because these are at times the stakes of failure in software engineering as well: our work touches on every part of life, including transportation, health, and safety systems.

Before Class

• Read Reading Note #3
• Watch my mini-lecture on Learning From Failure (Part 1)
• Oregon Whale Incident: Read article and watch 4m video: https://www.registerguard.com/story/lifestyle/2024/11/11/exploding-whale-day-florence-oregon-coast/76092539007/
• Tacoma Narrows Bridge:
  • Watch documentary footage: https://en.wikipedia.org/wiki/File:Tacoma_Narrows_Bridge_destruction.ogv
  • Read article and watch 5m video about the event: https://www.cascadepbs.org/2019/08/how-washingtons-most-infamous-bridge-failure-helped-engineers-prevent-more
• Hyatt Regency walkway collapse
  • Listen to: https://timharford.com/2022/03/cautionary-tales-death-on-the-dance-floor/ [47m]
  • Wikipedia article about the collapse: https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse -- note the 'Investigation' section and accompanying diagram
• Read excerpts from Success Through Failure and To Engineer is Human both by Henry Petroski.

Class Goals:

• Discuss Reading Note 2
• Standup
• Hands-on / triage issues with Task 2

Optional Reading:

• If you'd like to read about Brooks' idea of the roles in a software development team, read Chapter 3 of The Mythical Man Month; we won't cover this in class.
• If you'd like to read about Brooks' idea of developing a coherency in operating system architecture, read Chapter 4 of The Mythical Man Month; we won't cover this in class.
• If you are curious about the Tacoma Narrows Bridge Collapse, you might enjoy the Wikipedia article
• If you can't get enough of the exploding whale incident, it also has a Wikipedia article

October 9 (Thursday) Learning from Failures and Fiascos Part 2

Case:

• An unusual CVE
• Janet Jackson
• https://timharford.com/2023/03/cautionary-tales-office-hell-the-demise-of-the-playful-workspace/ [37m]
• Return to office failures
• something very directly related to agile / pmo ?

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

October 10 (Friday)

Bot Project Task 2 is due (release version 1.0).

October 14 (Tuesday) -- Collecting and Evaluating Evidence

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

materials from 'making software'

Optional Reading:

October 16 (Thursday) -- DevOps and Dora

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

October 17 (Friday)

Bot Project Task 3 is due (version 1.1)

Between-Sprint Planning

October 21 (Tuesday) -- Static Analysis

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

October 23 (Thursday) -- Testing and CI / CD

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

October 24 (Friday)

Task 4 is due

October 28 (Tuesday) -- Design Patterns

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

October 30 (Thursday) -- Architecture and Systems

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

October 31 (Friday)

Task 5 Due

Sprint 2

November 4 (Tuesday) -- Infrastructures and Supply Chains (Part 1)

Case: Log4J

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

November 6 (Thursday) -- Infrastructures and Supply Chains (Part 2)

Case: Leftpad

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

November 11 (Tuesday) -- Requirements

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

November 13 (Thursday) Metrics

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

November 21 (Friday)

Bot Project Task 6 (version 2.0) Due

Between-Sprint Planning

November 25 (Tuesday) -- Demo Day!

Demo Day!

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

November 27 (Thursday)

US Thanksgiving: No class!

December 1 (Monday)

Demo feedback due, 11:59 p.m. Pacific time.

December 2 (Tuesday) - Costing, Estimation, and Maintenance

Sprint Planning

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

Sprint 3

December 4 (Thursday) - Decomissioning

Lectures: (watch before class)

Resources:

Required Reading: (read before class)

Optional Reading:

December 9 (Tuesday)

No class meeting. However, this is the designated timeslot for the final exam for this class. I strongly recommend that you plan to co-work with your group during this time (Professor Champion will run an open lab during this period).

December 11 (Thursday)

Task 7 (Final version of your bot) due!

December 14 (Sunday)

Reflection Due

Administrative Notes

Teaching and learning after periods of disruption

Global events have a tremendous impact on all of us. Many of you missed key portions of the K-12 experience due to the pandemic or have experienced substantial stress due to circumstances beyond your control. We may be struggling to recover our own mental and physical health. Many of us are developing a sense of a "new normal".

As your instructor and colleague, I commit to do my best to approach the course in an adaptive, generous, and empathetic way. I ask that you try to extend a similar attitude towards everyone in the course. When you have questions, feedback, or concerns, please try to share them in an appropriate way. If you require accommodations of any kind at any time, please contact me.

Your Presence in Class

As detailed in section on case studies and in my detailed page on assessment, your homework in the class is to prepare for cases as well as to work on projects. Case discussion and team standup are an important ways that I will assess your learning. Obviously, you must be in class in order to participate. If you need to miss class for any reason, please fill out the course absence form so that I know you are not coming and do not include you in my cold call list. In the event of an absence, you are responsible for obtaining class notes, handouts, assignments, etc.

There are many students who have eagerly requested to join the class, but there are not enough seats. I want to include as many students in the class as possible. I will automatically drop anyone who misses the first two class sessions and try to replace them with unenrolled students who do attend. This is consistent with college policy and with the course description in the catalog.

Devices in Class

I ask you to stay focused and avoid distractions for yourself and your peers in the classroom. Spending class time gaming and shopping is a waste of your precious dollars and your precious minutes here --- live, face-to-face opportunities to learn are getting harder to find and they mean so much when we engage with them. That said, you are an adult, and I myself cannot imagine taking a class without being able to take notes on a device and look up topics as they come up. Learning to be present and to control our attention is part of being a modern adult. I promise not to spend class time goofing off online and I think you owe it to yourself to promise the same.

Office Hours

The best way to get in touch with me about issues in class will in the Discord server via asychronous messages sent to one of the text channels. This is preferable because any questions you have can be answered in a way that is visible to others in the class.

My available hours are visible in this calendar scheduling site. If my planned availability does not work for you, please contact me in the Discord server or over email to arrange a meeting at another time.

Religious Accommodations

Washington state law requires that UW develop a policy for accommodation of student absences or significant hardship due to reasons of faith or conscience, or for organized religious activities. The UW’s policy, including more information about how to request an accommodation, is available at Religious Accommodations Policy. Accommodations must be requested within the first two weeks of this course using the Religious Accommodations Request form.

Student Conduct

The University of Washington Student Conduct Code (WAC 478-121) defines prohibited academic and behavioral conduct and describes how the University holds students accountable as they pursue their academic goals. Allegations of misconduct by students may be referred to the appropriate campus office for investigation and resolution. More information can be found online at https://www.washington.edu/studentconduct/

Safety

Call SafeCampus at 425-352-5359 anytime–no matter where you work or study–to anonymously discuss safety and well-being concerns for yourself or others. SafeCampus’s team of caring professionals will provide individualized support, while discussing short- and long-term solutions and connecting you with additional resources when requested.

Use of AI Tools

In this course, students are permitted to use AI-based tools (such as UW’s version of Copilot) on some assignments. The instructions for each assignment will include information about whether and how you may use AI-based tools to complete the assignment. All sources, including AI tools, must be properly cited. Use of AI in ways that are inconsistent with the parameters above will be considered academic misconduct and subject to investigation.

Please note that AI results can be biased and inaccurate. It is your responsibility to ensure that the information you use from AI is accurate. Additionally, pay attention to the privacy of your data. Many AI tools will incorporate and use any content you share, so be careful not to unintentionally share copyrighted materials, original work, or personal information.

Learning how to thoughtfully and strategically use AI-based tools may help you develop your skills, refine your work, and prepare you for your future career. If you have any questions about citation or about what constitutes academic integrity in this course or at the University of Washington, please feel free to contact me to discuss your concerns.

Please note that I do not consider grammar/spellchecking to be a prohibited use of AI, even when other uses for AI are not allowed.

Adapted from: UW sample syllabus statements.

Academic Dishonesty

This includes: cheating on assignments, plagiarizing (misrepresenting work by another author as your own, paraphrasing or quoting sources without acknowledging the original author, or using information from the internet -- including from AI tools -- without proper citation), and submitting the same or similar paper to meet the requirements of more than one course without instructor approval. Please note that fabricated citations are a form of academic dishonesty. Academic dishonesty in any part of this course is grounds for failure and further disciplinary action. The first incident of plagiarism will result in the student’s receiving a zero on the plagiarized assignment. The second incident of plagiarism will result in the student’s receiving a zero in the class.

Disability Resources

If you have already established accommodations with Disability Resources for Students (DRS), please communicate your approved accommodations through their processes at your earliest convenience so we can discuss your needs in this course.

If you have not yet established services through DRS, but have a temporary health condition or permanent disability that requires accommodations (conditions include but not limited to; mental health, attention-related, learning, vision, hearing, physical or health impacts), you are welcome to contact DRS at 425-352-5426 or uwbdrs@uw.edu or disability.uw.edu. DRS offers resources and coordinates reasonable accommodations for students with disabilities and/or temporary health conditions. Reasonable accommodations are established through an interactive process between you, your instructor(s) and DRS. It is the policy and practice of the University of Washington to create inclusive and accessible learning environments consistent with federal and state law.

Mental Health

Your mental health is important. If you are feeling distressed, anxious, depressed, or in any way struggling with your emotional and psychological wellness, please know that you are not alone. College can be a profoundly difficult time for many of us.

Resources are available for you:

• UW 24/7 Help Line 1.866.775.0608
• https://wellbeing.uw.edu/topic/mental-health/
• https://www.crisistextline.org/
• https://www.uwb.edu/student-affairs/counseling

Other Student Support

Any student who has difficulty affording groceries or accessing sufficient food to eat every day, or who lacks a safe and stable place to live, and believes this may affect their performance in the course, is urged to contact campus advising and counseling services for support. Furthermore, please notify the professors if you are comfortable in doing so. This will enable us to provide any resources that we may possess. Please also note the student food pantry, Any Hungry Husky.

Credit and Notes

This course was inspired by the course notes shared with me authored by Jeff Stride, Arkady Retik, and Hazeline Asuncion. In developing the content and approach, I drew from research into effective teaching techniques and challenges facing computer science students, including:

• Oram A, Wilson G. 2011. Making software : what really works, and why we believe it. 1st ed. Sebastopol, Calif: O’Reilly.

• Wilson, G., Aranda, J., Hoye, M., Johnson, B.: Experience report: It will never work in theory. IEEE Software 41(03), 80–82 (May 2024). https://doi.org/10.1109/MS.2024.3362649

• Liao, Y. C., & Ringler, M. (2023). Backward design: Integrating active learning into undergraduate computer science courses. Cogent Education, 10(1). https://doi.org/10.1080/2331186X.2023.2204055

• K. Banweer and D. A. Trytten, "WIP: Code Insight: Combining Code Reading and Debugging Practices for Active Learning in Entry-Level Computer Science Courses," 2024 IEEE Frontiers in Education Conference (FIE), Washington, DC, USA, 2024, pp. 1-5, doi: 10.1109/FIE61694.2024.10893296.

• K. Beck (2025). [Legitimate Peripheral Participation| https://tidyfirst.substack.com/p/legitimate-peripheral-participation] Blog post on Substack.