Software Engineering (Fall 2026)

From CommunityData
CSS360: Software Engineering
Instructor: Kaylea Champion
--> Going to be absent? Avoid a cold call penalty! <--
Contact: Your messages are important to me! 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. That said, 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 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:
Section D:
Tuesday / Thursday
5:45 PM to 7:45 PM
UW1 room 060
Section E:
Tuesday / Thursday
11:00 AM to 1:00 PM
UW1 room 102
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 on Canvas.)
  • Section D (545-745) Course absence form: It is important to tell me if you are not coming to class at least one hour before class begins.
  • Section E (11-1) 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 2026 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.
Weather Notes
As a fall quarter course, there is a small chance that extreme weather will make in-person meetings impossible. In this case, my plan is always to hold class, but to do so via Zoom rather than in-person. I will make announcements and pass along information as I receive it, but you should anticipate we will have class in some form unless you hear otherwise.

Overview[edit]

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[edit]

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 evaluate your progress. You might notice that we often read about a concept, discuss it, do a lab about it, and then apply it to our project: this is intentional :-). You might also notice that we introduce a basic idea, and then return to it later in an expanded form: this is also intentional :-).

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. Do not rely on AI tools to do your reading and lecture-watching for you.

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. For my more focused attention, please book an office hours appointment with me. If you prefer an in-person appointment, please let me know. I am not always on campus (especially not on Mondays, and only some Fridays), so we will need to do some extra coordination to make in-person happen. 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.
  5. Conduct labs and in-class activities
  6. Do concept-check and reading quizzes

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[edit]

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

  • You will use AI tools, primarily locally hosted models, but some assignments will engage with commercial AI products such as Chat GPT, Claude, UW Purple, Microsoft CoPilot, and Gemini
  • wiki.communitydata.science — This website hosts the public syllabus for the course. 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.

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[edit]

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.

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. If you plan to work more than six days ahead, contact me first.

Closely monitor your email or the announcements section on the course website on Canvas to make sure you don't miss announcements.


Assignments[edit]

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 many labs, a comprehensive project and have one writing assignment reflecting on that project and course topics. 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[edit]

Discussion[edit]

The course makes substantial use of discussion. It is important to realize that if I ask you to prepare something out of class, I will not summarize the material in class or cover it in lecture. I expect you all to have read it or watched it and we will jump in and start discussing it. Generally speaking, there are multiple right answers in discussion, and there are definitely poorly-prepared answers versus carefully-considered ones!

Cold Calling[edit]

I make use of 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: a typical tech job includes very few if any lectures (except for "all hands" type meetings and "training" activities), and a range of types of team meetings and group conversations, where you will be expected to be prepared and then participate in key moments.

Because I understand that cold calling can intimidate some students, I will be circulating a list of questions (labeled "Reading Note" in the syllabus) that we will discuss. These will be finalized 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. Do not ask AI to answer these questions for you and do not plan to read verbatim from a prepared answer. You should instead work in advance to read and watch the material I share, and anticipate that I will ask follow-up questions or invite you to engage with the answers of others (or that these questions will appear, perhaps in a modified form, as the source of concept checks and reading quizzes). You are welcome to work with other students to brainstorm possible answers prior to class. Although I may also ask spontaneous questions that I do not distribute ahead of time, I will not 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[edit]

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.

Reading quizzes[edit]

I use brief, low-stakes quizzes to make sure students are understanding material and are prepared. Preparation for these checks and quizzes is the same as preparation for discussion and for any other topic: read the material, watch the videos, look up terms you don't understand and be ready to discuss answers to the questions in the reading note. There will be 13 reading quizzes over the course of the quarter, and I will drop the lowest 3 scores. These quizzes will be positioned at the beginning of class and should be done entirely in formal testing conditions -- no notes or materials, no phones or electronics: just you, a pencil or pen, and the quiz paper I distribute to you. Reading quizzes cannot be made up.

Labs[edit]

This class includes many labs: we have Runestone labs to learn Git and GitHub, SWE Skills labs to learn software engineering skills, and AI SWE labs to learn AI-related software engineering skills. Labs are designed to be straightforward: follow the steps, apply a bit of the learning we've done so far, and you should get all the right answers. Each lab should give you the chance to add a new practical skill to your toolbox: a skill you will then apply to your more open-ended, creative, and uncertainty-filled group project. Labs can be finished after class.

Sprint Planning Meetings[edit]

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. Note that work you do in GitHub as part of sprint planning will be scored. Sprint planning deliverables can be finished after class.

Standup Meetings[edit]

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? To receive credit for standup, document your standup work on Discord. If you are in class, document standup in class. If you miss class, you may enter your standup participation during class time -- otherwise, participation will not be counted and receiving more cold call questions will be your opportunity to recover credit.

Out of Class: Read, Watch, Write, and Code[edit]

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[edit]

You will participate in a group project to build a Discord bot as part of this class. 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[edit]

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

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 only 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[edit]

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[edit]

Task
Set up your project environment
Due
Friday, October 16, 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. Fork the example to create a group-level repository, and create a Kanban board to track work associated with your fork; it's ok to just use the provided Kanban template. (in class) [TODO Some screenshots of the process] Make sure your board is part of the class organization and you enable 'issues' when you create the Github Repository so that Dr. Champion can add issues you will track on your Kanban board.
  3. Create a personal fork of your team's fork.
  4. Create a Discord deployment server (one per group) (in class). [TODO Some screenshots of the process] and Discord has a how-to page as well.
  5. Create a Discord test server (one per student).
  6. Update your group's GitHub repository settings and README.md so that the front page reflects the state of your project.
  7. Add some ideas to your Kanban board reflecting what you might like a discord bot to do (brainstormed ideas are great)
  8. All group members and Dr. Champion need invites to and should join all group environments.
  9. 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!
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.
  • Your Discord token needs to be kept private. If you keep your repository private, you can save your token in your .env file. But a repository that is publicly visible can't have a discord token in it. If the repository is public, you can launch the codespace, then edit the .env file, and then launch your app.

Bot Project Task #2[edit]

Task
Version 0.1 of your bot
Due
Friday, October 23rd, 11:59 p.m. Pacific time
Deliverables
You are done with task 2 if you have:
  1. cloned your group repository from our class organization
  2. deployed a working Discord bot in your individual test environment
  3. deployed a working Discord bot in your team's deployment environment ('working' in this case means, able to create the simple interaction shown in the tutorial).
  4. refined your brainstormed bot ideas into user stories
Turn In
2 Screenshots with a visible chat history which demonstrates that this is the case: one for your group deployment of the bot, one for your personal test server version of the bot.

Steps

  1. We will be using Codespaces in GitHub to deploy your bot. This means all of your work goes on in the cloud without impacting your computer. However, it's not the only way to do things; if you would prefer a different working environment, you might be interested in these alternate environment instructions.
  2. Your codespaces hostname goes into the Discord Developer portal (same place you got your tokens) in the box 'Interactions Endpoint URL'

Bot Project Task #3[edit]

Task
Version 1.0 of your bot
Due
Friday, October 30, 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 you developed -- or which were supplied by Dr. Champion -- for your first sprint and successfully deployed the updated bot to your group deployment environment for Dr. Champion to review. Tag the code so that it is clear which version is 1.0. See list of steps for all the items you'll be graded on.
Turn in
1) A screenshot of version 1.0 of your bot in action in the group environment, depicting the feature you implemented in your user story and 2) an estimate of how long it took you to do the work (just a sentence with your Canvas screenshot is plenty).

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 and test often, with clear commit messages.
  4. Open a pull request to merge your branch into the team's main.
  5. Review your pull requests for conflicts.
  6. Merge code and tag a release when done with the sprint scope with release notes and updates to your project description and README.md
  7. Update your Kanban board and mark stories as resolved (make sure they are well-formatted and complete user stories...)
  8. Deploy your version 1.0 into the group deployment environment
  9. Make sure any issues with the previous submissions are resolved.
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!
  • 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.
  • If your code lands later and you miss the 1.0 tag, or you discover bugs after the tag has happened, you can tag a new release of 1.0.1, 1.0.2 (etc.)

Bot Project Task #4[edit]

Task
Analyze the architecture of your assigned bot
Due
Friday, November 6, 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 (ARCHITECTURE.md). All group members should have made at least one substantive commit to the guide to receive credit. See list of steps for all the items you'll be graded on.
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. Each team member should do at least one diagram from the following types: data flow diagram (DFD), activity diagram, system context diagram, network diagram, control-flow graph, class diagram, use case diagram. If your chosen diagram is trivial, you should do more than one to receive full credit.
  4. Be concise and accurate in your description and clear in your diagrams. Follow the linked instructions as best you can; Miro is a good tool for this, but you can use whatever tool you like; it's also possible to write diagrams in markdown in GitHub.
Tips
  • Divide up the work so that everyone has a piece to contribute
  • Include both system architecture and code architecture.
  • If you are short on ideas, here are a few: what patterns does your code use? If someone wants to add new functionality, how should they do that? How is npm involved? How does Codespaces work? How does your code make things happen in Discord? How is the network functioning?
  • 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[edit]

Task
Identify bugs, gaps, and technical debt in your bot and start closing the gaps
Due
Friday, November 13, 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 group repository (everyone from the group should contribute to a single report) 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. See list of steps for all the items you'll be graded on.
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 and code hardening into tasks for each group member, choosing two from the following:
    1. Examine your code for technical debt and code smells.
    2. Assess the cyclomatic complexity of the methods in your bot.
    3. Measure your cohesion and coupling (architecture diagrams might help with this!).
    4. Measure your test coverage.
    5. Build a threat model.
    6. Write a fuzzer to try to break functionality in your bot (see Fast-check for a short intro to running fast-check tests in Codespaces).
    7. Unit tests. Write at least 3, these are easy and quick.
    8. Smoke test. If you don't have one already, write a test that will call all the major functions in your bot and verify that core features are working.
    9. Implement continuous integration / continuous deployment for your bot.
    10. Your own idea about what the bot needs (propose a scope to Dr. Champion)
  2. Describe your efforts and findings in a shared code analysis report in your repo.
  3. Create user stories associated with your findings (at least 2 per person; you must write out the story yourself).
Tips
  • Think about how your bot has been used so far. What did your testers say? Did anyone try anything that didn't work or wasn't supported? Maybe that's a bug or feature request?
  • Think back to when you were writing the bot. Did you cut any corners or implement something quick and dirty, planning to come back to it later?
  • 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[edit]

Task
Release version 2.0
Due
November 29 (Sunday), 11:59 p.m. Seattle time.
Deliverables
You are done with Task 6 if you have each completed at least one very large or three small user stories from your second sprint and deployed version 2 to your production environment for Professor Champion to review. Note the rubric on Canvas for this. Tag the code so that it is clear which version is 2.0. See list of steps for all the items you'll be graded on.
Turn in
A screenshot of version 2.0 of your bot in action with comments and links to your work, as well as reflections (see rubric)

Steps

  1. In sprint planning, assign user stories to each member of the group. Note the rubric on Canvas for this task.
  2. During the sprint, resolve user stories. User stories should be well-formed: assigned, estimated, with specifications: inputs, outputs, acceptance criteria. Link them to the pull request.
  3. Commit often! Test often! Make sure your commit messages make sense.
  4. Open a pull request to merge your feature branch into the team's main branch.
  5. Review your pull requests for conflicts.
  6. Include an up-to-date SBOM with your release in a standards-compliant format.
  7. Merge code and tag a release when done with the sprint scope.
  8. Deploy your version 2.0 into the production environment.
  9. Update your Kanban board and issue release notes.
  10. Repository must be clean and clear. If you have files from previous releases, they should be clearly marked.
Tips
  • Feel free to use AI tools as a tutor or source for debugging any issues that come up.
  • Be disciplined in your use of GitHub: use feature branches, pull requests, link pull requests and the user stories they resolve.
  • Clean up your own messes: don't expect others to fix your conflicts.

Bot Project Task #7[edit]

Task
Release version 2.1
Due
Thursday, December 17, 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 medium sized (or two small, or many tiny) user stories 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. See list of steps for all the items you'll be graded on.
Turn In
Screenshots of each new feature added for v2.1 and links to the user stories you completed.

Steps

  1. In sprint planning, think about how your demonstration went and reflect on what refinements you'd like to make
  2. Assign user stories to each group member.
  3. Complete at least one well-defined and complete user story.
  4. Commit, test, merge as usual.
  5. Tag a release as 2.1 and update the SBOM
  6. Deploy version 2.1 and screenshot for turn-in purposes.
  7. Update your Kanban board and release notes.
  8. Add a time estimate and reflection as prompted in the assignment.
  9. Repository must be clean and clear. If you have files from previous releases, they should be clearly marked.
Tips
  • You should expect that the grading for 2.1 will be less forgiving than the grading for 2.0, since you are now very familiar with the processes and requirements.
  • 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[edit]

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[edit]

Task: Record a pre-made demo of your bot (8-10 minutes).

Due
Monday, November 30, 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[edit]

Task: Conduct a live demo of your bot

Due
In class on Tuesday, December 1st.
Deliverables
During your 10 minute slot, show your project. See list of steps for all the items you'll be graded on.
Turn In
no artifact -- just be present and prepared. The full group should expect to stand up front and be involved.

Steps

  1. I'll determine an order for presentation
  2. Make sure your team has discussed how to present the work, including logistics and assignments.
    1. Who will do what?
    2. What did you learn about how to demo your bot 'live' from making your pre-recorded demo?
    3. If you have a 'two-player' or 'observers and contestants' type features, how will you demonstrate the two players or multiple views?
    4. If you have some randomness in behaviors, how will you trigger / display all of the features?
  3. Slides are not necessary, but a view of your bot in action is.
  4. To avoid awkwardness around switching laptops, the podium computer 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.
  5. We'll allow time for questions / clarifications after the presentation.
  6. Grade will be based on preparation (is the bot bug-free and rigged so that a demo can happen?) and participation (do all group members have a role to play?)
Tips
  • In case of live demo failure, be prepared to share your pre-made demos as a fallback so that you can get good feedback.

Bot Feedback[edit]

Task: give feedback to 2 other groups

Due
Wednesday, December 2, 11:59 p.m.
Deliverables
a paragraph of highly specific feedback for the group you are assigned; grading will be according to my detailed rubric for giving feedback in brief.
Turn In
a text submission on Canvas
Tips
  • I will assign you to give feedback to two projects from other groups.
  • You will work individually; each group will get feedback from multiple peers as well as from me.
  • 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[edit]

Due
Sunday, December 20, 11:59 p.m. Pacific Time

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. Mention commit IDs, line numbers, dates & times as appropriate.
  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 1000-1500 words. Under 800 is unlikely to achieve the depth I am seeking here, and over 1600 words is unfair to others.
  5. Do 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? Did you experience any failures or problems? How did you solve them? 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. Choose and use a formatting standard and stick to it (APA, Chicago, ACM, etc.). 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[edit]

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:

  • Discussion and standups: 30%
  • In-class quizzes (reading quizzes and concept checks): 10%
  • Labs (Runestone Labs 1-4, SWE Skills Labs 1-3, AI in SWE Labs 1-3): 10%
  • Sprint 1 (Bot Tasks 1-3): 10%
  • Sprint 2 (Bot Tasks 4-6): 15%
  • Sprint 3: (Bot Task 7) 10%
  • Presentation (Includes Demo, Pre-made Demo, and Feedback): 10%
  • 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 discussion and standup 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 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 discussion and standup portion of the grade as I will not be cold calling the same person an excessive number of times in a single class session.

Standup participation is equivalent to answering one question in class. This participation must be done during class hours so that your groupmates can understand the overall state of the project at the same time. Missed standup will result in more cold call questions as part of the same self-balancing approach. Standup should not use AI (this is about telling your groupmates where you are with your tasks, what your plans are, and whether you are having any trouble).

In-class quizzes cannot be made up, but there will be 13 of them over the quarter and I will drop the lowest 3 scores. Quizzes are done under formal testing conditions: no notes, no electronic tools, no discussion, eyes on your own paper, everything put away except a writing implement.

Labs may be more challenging for some students than others and can be completed outside of class -- but are designed to be easier to do in class collaboratively. You can use AI assistance with lab assignments, but the results may or may not be reliable.

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 1 week 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 overall, 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 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 (what if life gets busy or messy later in the quarter?), 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 Tasks 1-6, you may choose one task for which you want to use one 48-hour extension per quarter, no questions asked (however, you must file for an extension before the due date and time of the assignment). 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!).

Late completion of activities and tasks will lead to a 20% penalty per 48 hour period. Some tasks are holistic (in which case, it's either on-time or it's not), but others are multi-part, with each part having its own share of the credit for the assignment; in some cases it may be impossible to distinguish late pieces from on-time pieces and in those cases late penalties will be assigned across the assignment.

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 much harder to resolve code conflicts and coordination problems.

Do not expect your groupmates to do extra work to accommodate your need for an extension.

No extension is possible for Quizzes or Labs: we need to keep progressing forward with content, including discussing the content of the quiz or the lab.

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[edit]

This schedule describes our topics over the coming days and weeks. Please note that the UW has a formal schedule for when you can drop or withdraw.

Sprint 1 -- Planning Phase[edit]

October 1 (Thursday): Introduction to the Course, Software Engineering, and SDLC[edit]

October 2 (Friday): DUE: Class Checklist[edit]

Required Task: Complete the class setup checklist, linked on Canvas. 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.

October 4 (Sunday): DUE: AI in SWE Lab 1 (Syllabus Tool)[edit]

October 6 (Tuesday): Organizing Patterns: Agile, Waterfall, and All That[edit]

October 8 (Thursday): The Problem of Coordination (Git, GitHub, and Going Global)[edit]

Noah Smith lecture today at 630 in Mobius Hall! https://events.uw.edu/event/ChatbotShmatbot/summary

October 11 (Sunday) DUE: Runestone Lab 1[edit]

October 13 (Tuesday) Learning from Failures and Fiascos Part 1 ONLINE VIA ZOOM[edit]

October 15 (Thursday) Learning from Failures and Fiascos Part 2 ONLINE VIA ZOOM[edit]

Friday, October 16: DUE: Bot Task 1[edit]

Sunday, October 18: DUE: Runestone Lab 2[edit]

Sprint 1 -- Execution Phase[edit]

October 20 (Tuesday) -- Gathering and Analyzing Requirements[edit]

October 22 (Thursday) -- Design Part 1: Patterns[edit]

October 23 (Friday) Bot Task 2 (version 0.1) is Due![edit]

October 25 (Sunday) Runestone Lab 3 (Ch 4) is due![edit]

October 27 (Tuesday) -- Design Part 2: Architecture and Systems[edit]

October 29 (Thursday) -- Testing and CI / CD[edit]

October 30 (Friday) Bot Task 3 (version 1.0) is Due![edit]

November 1 (Sunday) Runestone Lab 4 (Ch 5) is due[edit]

Sprint 2 -- Planning Phase[edit]

November 3 (Tuesday) -- Security and Threat Modeling[edit]

November 5 (Thursday) -- Evidence Part 1: Static Analysis, Fuzzing, and Scanning[edit]

November 6 (Friday) DUE: Bot Task 4 AND SWE Skill Lab 0 (Testing, Extra Credit)[edit]

November 8 (Sunday) DUE: SWE Skills Lab 1 (Static Analysis)[edit]

November 10 (Tuesday) -- Evidence Part 2: Evaluating Evidence, DevOps and Dora[edit]

November 12 (Thursday) -- Infrastructures and Supply Chains (Part 1) PROBABLY ONLINE VIA ZOOM[edit]

November 13 (Friday) Bot Task 5 Due[edit]

Sprint 2 -- Execution Phase[edit]

November 17 (Tuesday) -- Infrastructures and Supply Chains (Part 2)[edit]

November 18 (Wednesday) SWE Skills Lab 2 (SBOM) Due![edit]

November 19 (Thursday) -- Agentic Development[edit]

November 20 (Friday) AI in SWE Lab 2 Due![edit]

November 24 (Tuesday) -- Code review[edit]

November 29 (Sunday)[edit]

Bot Task 6 (version 2.0) is due.

Sprint 3 -- Planning Phase[edit]

November 30 (Monday)[edit]

Pre-made demos of your bot are due today at 11:59 p.m. Pacific time.

December 1 (Tuesday) -- Demo Day![edit]

Demo Day! Your demo of your bot should be done live in class today

December 2 (Wednesday)[edit]

Your bot demo feedback is due, 11:59 p.m. Pacific time.

December 3 (Thursday): Costing, Estimation, and Maintenance[edit]

Sprint 3 -- Execution Phase[edit]

December 8 (Tuesday) - Quality, the -ibles, and Trade-offs[edit]

December 9 (Wednesday) SWE Skills Lab 3 (Estimation) Due[edit]

December 10 (Thursday) - Decomissioning, Handoffs, and Transitions[edit]

December 11 (Friday) DUE: AI in SWE Lab 3[edit]

December 15 (Tuesday)[edit]

No class meeting. However, this is the university-designated timeslot for the final exam for this class, which means all of your group members have this time free. 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 17 (Thursday)[edit]

Bot Project Task 7 (Final version of your bot) due at 11:59 p.m. Pacific time.

December 20 (Sunday)[edit]

Reflection Due

Administrative Notes[edit]

UW Bothell STEM has a set of standard policies for undergraduates. In the case that one of the statements in this syllabus contradicts school or UW policy, of course school and UW policy prevail. If you see contradictions or issues with clarity, I hope you will share them with me ASAP so that I may resolve them for everyone's benefit.

Teaching and learning after periods of disruption[edit]

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[edit]

As detailed in section on case studies and discussion and in my detailed page on assessment, your homework in the class is to prepare for discussion 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 in some cases there are not enough seats. I want to include as many students in the class as possible. If we run out of space, I may need to 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[edit]

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[edit]

The best way to get in touch with me about issues in class will be 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[edit]

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[edit]

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[edit]

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[edit]

In this course, students are permitted to use AI-based tools (such as UW Purple) 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. As part of the CSS department initiative to be consistent with respect to student evaluation, assignments in this course only use AI in intentional ways, and evaluation is AI-frictioned, that is, proctored to challenge you to answer using your own skills rather than trivial copy-paste from AI.

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/translation to be a prohibited use of AI when reading, listening to / watching my lectures to prepare for class discussion, or when developing your final reflection.

Adapted from: UW sample syllabus statements.

Academic Integrity[edit]

The University takes academic integrity very seriously. Behaving with integrity is part of our responsibility to our shared learning community. If you’re uncertain about whether something is academic misconduct, ask me. I am willing to discuss questions you might have.

Acts of academic misconduct may include but are not limited to:

  • Cheating (sharing questions or answers to a quiz, using unauthorized materials to complete a quiz -- all quizzes in this class are under formal exam conditions: no notes, no reading material, no devices of any kind)
  • Plagiarism (representing the work of others as your own without giving appropriate credit to the original author(s))
  • Submitting the same assignment to meet the requirements of more than one course without instructor approval
  • Fabricating citations, data, or results.

Concerns about these or other behaviors prohibited by the Student Conduct Code will be referred for investigation and adjudication by the appropriate UW Bothell office.

Students found to have engaged in academic misconduct may receive a zero on the assignment and be reported to the campus conduct office for a first offense. A second offense will result in the student receiving a zero in the class.

Disability Resources[edit]

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[edit]

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:

Other Student Support[edit]

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 me if you are comfortable in doing so. This will enable me to pass along any additional resources that I may know about. Please also note the student food pantry: the UWB Husky Pantry.

Credit and Notes[edit]

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:

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