Editing Software Engineering (Winter 2026) (section)

= 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—an event and the surrounding context, or an organization or group. 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 multiple right answers in cases, and there are definitely poorly-prepared answers versus carefully-considered ones!

==== Cold Calling ====

Cases rely roughly on the [[:wikipedia:Socratic method|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: very few 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. 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 [[User:Kaylea/Assessment#Case Discussion|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. Note that work you do in GitHub as part of sprint planning will be scored as part of your sprint grade.

=== 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? To receive credit for standup, you must be present in the standup '''and''' participate in standup during class '''and''' document your standup work on Discord.

== 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 [[User:Kaylea/Assessment| the detailed page on assessment]] gives the rubric I will use to evaluate these projects.

The "Writing Rubric" section of [[User:Kaylea/Assessment| 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: Wednesday, January 21, 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'''
# Devise a team name. (in class)
# 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) [https://canvas.uw.edu/courses/1878637/files?preview=143554731 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.
# Create a personal fork of your team's fork.
# Create a Discord deployment server (one per group) (in class). [https://canvas.uw.edu/courses/1878637/files?preview=143554737 Some screenshots of the process] [https://support.discord.com/hc/en-us/articles/204849977-How-do-I-create-a-server and Discord has a how-to page as well.]
# Create a Discord test server (one per student).
# Update your group's GitHub repository settings and README.md so that the front page reflects the state of your project.
# Add some ideas to your Kanban board reflecting what you might like a discord bot to do (brainstormed ideas are great)
# All group members and Dr. Champion need invites to and should join all group environments.
# 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 ====
;Task: Version 0.1 of your bot
;Due: Friday, January 23rd, 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
# 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). 
# 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'''
# 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 [[CSS360_docker_environment_instructions|alternate environment instructions]].
# 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 ====
;Task: Version 1.0 of your bot
;Due: Friday, January 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'''
# In sprint planning, assign one of the user stories written by Dr. Champion or by the team to each member of the group.
# During the sprint, resolve that user story.
# Commit and test often, with clear commit messages.
# Open a pull request to merge your branch into the team's main.
# Review your pull requests for conflicts.
# Merge code and tag a release when done with the sprint scope with release notes and updates to your project description and README.md
# Update your Kanban board and mark stories as resolved (make sure they are well-formatted and complete user stories...)
# Deploy your version 1.0 into the group deployment environment
# 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 ====
;Task: Analyze the architecture of your assigned bot
;Due: Friday, February 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'''
# Think about the levels or facets of system architecture involved in your project.
# Identify a layer or aspect for each group member to cover. 
# Each team member should do at least one diagram from the following types: [https://en.wikipedia.org/wiki/Data-flow_diagram data flow diagram (DFD)], [https://en.wikipedia.org/wiki/Activity_diagram activity diagram], [https://en.wikipedia.org/wiki/System_context_diagram system context diagram], [https://en.wikipedia.org/wiki/Computer_network_diagram network diagram], [https://en.wikipedia.org/wiki/Control-flow_graph control-flow graph], [https://en.wikipedia.org/wiki/Class_diagram class diagram], [https://en.wikipedia.org/wiki/Use_case_diagram use case diagram]. If your chosen diagram is trivial, you should do more than one to receive full credit.
# Be concise and accurate in your description and clear in your diagrams. Follow the linked instructions as best you can; [https://www.miro.com 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 ====
;Task: Identify bugs, gaps, and technical debt in your bot and start closing the gaps
;Due: Friday, February 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.
<!-- in future, have students turn in links and be more specific on pieces of the analysis -- what they did, what they found, what should be done. have everyone write unit tests and don't have that as an option -->
'''Steps'''
# Divide up the different perspectives on code analysis and code hardening into tasks for each group member, choosing ''one'' from the following:
## Examine your code for technical debt and code smells.
## Assess the cyclomatic complexity of the methods in your bot. 
## Measure your cohesion and coupling (architecture diagrams might help with this!).
## Measure your test coverage.
## Build a threat model.
## Write a fuzzer to try to break functionality in your bot.
## Unit tests. Write at least 3, these are easy and quick.
## 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.
## Implement continuous integration / continuous deployment for your bot.
## Your own idea about what the bot needs (propose a scope to Dr. Champion)
# Describe your efforts and findings in a shared code analysis report in your repo.
# Create user stories associated with your findings (at least 1 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 ====
;Task: Release version 2.0
;Due: February 27 (Friday), 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'''
# In sprint planning, assign user stories to each member of the group. Note the rubric on Canvas for this task.
# 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. 
# Commit often! Test often! Make sure your commit messages make sense.
# Open a pull request to merge your feature branch into the team's main branch.
# Review your pull requests for conflicts.
# Include an up-to-date SBOM with your release in a standards-compliant format.
# Merge code and tag a release when done with the sprint scope.
# Deploy your version 2.0 into the production environment.
# Update your Kanban board and issue release notes.
# 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 ====
;Task: Release version 2.1
;Due: Thursday, March 19, 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'''
# In sprint planning, think about how your demonstration went and reflect on what refinements you'd like to make
# Assign user stories to each group member.
# Complete at least one well-defined and complete user story.
# Commit, test, merge as usual.
# Tag a release as 2.1 and update the SBOM
# Deploy version 2.1 and screenshot for turn-in purposes.
# Update your Kanban board and release notes.
# Add a time estimate and reflection as prompted in the assignment.
# 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 ===

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 (8-10 minutes).
;Due: Monday, March 2nd, 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, March 3rd.
;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'''
# I'll determine an order for presentation
# Make sure your team has discussed how to present the work, including logistics and assignments.
## Who will do what? 
## What did you learn about how to demo your bot 'live' from making your pre-recorded demo?
## If you have a 'two-player' or 'observers and contestants' type features, how will you demonstrate the two players or multiple views?
## If you have some randomness in behaviors, how will you trigger / display all of the features?
# Slides are not necessary, but a view of your bot in action is.
# 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.
# We'll allow time for questions / clarifications after the presentation.
# 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 ====

Task: give feedback to 2 other groups
;Due: Wednesday, March 4, 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. <!-- need to actually highlight this so I can hold accountable -->
;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 ====

;Due: Sunday, March 22, 11:59 p.m. Pacific Time

See the [[User:Kaylea/Assessment | brief reflection rubric]] for details on my expectations in terms of the content of the reflection. A successful essay will do the following things:

# Use content and concepts from the course.
# Use evidence from your experience and the bot project. Mention commit IDs, line numbers, dates & times as appropriate.
# 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.
# Be 1000-1500 words. Under 800 is unlikely to achieve the depth I am seeking here, and over 1600 words is unfair to others.
# 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 ===

I will follow the very detailed grading rubric described on [[User:Kaylea/Assessment|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 labs and case discussion: 50%
* Sprint 1: 10%
* Sprint 2: 15%
* Sprint 3: 15%
* Presentation (Includes Demo, Pre-made Demo, and Feedback): 5%
* Reflection: 5%

'''Impact of Missing Class'''
If you must miss class, must be late, or must leave early, file the [https://docs.google.com/forms/d/e/1FAIpQLSe4PvMjIdponoHug7c2QteM1cxJPhBnuob4nUutmkHd89uJ9Q/viewform?usp=publish-editor 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. 

Standup participation is equivalent to answering one question in class. There is no way to directly make up missing a standup meeting with your group -- you may find it useful to share an update on Discord, but there is no substitute for the synchronous and timely participation in a standup.

Lab completion is equivalent to answering two questions in class; labs may be more challenging for some students than others and can be completed outside of class.

'''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, note that the assignments are due Fridays at 11:59 p.m. Pacific time. Among these 6 project tasks, you may choose one task 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!). Late completion of activities and tasks will lead to a 20% penalty per 48 hour period. Some tasks include a requirement that screenshots be submitted; these are either on time or they're not. 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 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 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 [https://www.uwb.edu/registrar/incomplete-grade-policy 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.