Editing Software Engineering (Fall 2025) (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.

=== Standup Meetings ===

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

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

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

=== Projects === 

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

The "SW Engineering Project Rubric" section of [[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: Friday, October 3, 11:59 pm Pacific Time
;Deliverables: You are done with task 1 if you have a GitHub project environment, a Discord test server for yourself, and a Discord deployment server set up for your group, with all group members and Dr. Champion able to access both the project environment and your group's deployment server. This is a <60 minute task; don't over-complicate it!
;Turn In: A screenshot of your individual Discord test server, a screenshot of your Discord group deployment server, and a screenshot of your GitHub project environment.

'''Steps'''
# Devise a team name. (in class)
# Create a GitHub project environment (one per group) to match the name. Create a Kanban board to track your work; it's ok to just use the provided template. (in class) [Some screenshots of the process]
# Create a Discord deployment server (one per group) (in class). [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).
# 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!
# Make sure Dr. Champion has the power to add user stories into your project Kanban board (you will need these for task 3 and beyond).

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

==== Bot Project Task #2 ====
;Task: Version 1.0 of your bot
;Due: Friday, October 10, 11:59 p.m. Pacific time
;Deliverables: You are done with task 2 if you have cloned your group repository from our class organization, deployed a working Discord bot in your individual test environment, and deployed a working Discord bot in your team's deployment environment ('working' in this case means, able to play the simple 7-option rock-paper-scissors style game described in the tutorial). 
;Turn In: Screenshots with a visible chat history which demonstrates that this is the case.

'''Steps'''
# Follow the tutorial at https://discord.com/developers/docs/quick-start/getting-started closely -- with one exception: '''ignore the git command in the tutorial''' and instead '''fork [https://github.com/CSS360-2025-Fall/discord-example-app our class organization version] of the Discord sample app''' described in the tutorial. This will mean we all start with the same code even if Discord makes updates, any changes you make will not go to Discord HQ, you are working with the repository associated with your group, and your work will be attributed correctly.
# You will end up installing ngrok, npm, cloning the GitHub example, and establishing an identity with discord for your bot. 

;Tips:
* If you get stuck, walk through the tutorial line by line: it's detailed, and it works, but there are some subtleties.
* I found it helpful to do this phase on a pair of large monitors so that I could have all my windows open side-by-side.
* Be very careful with the API tokens and secrets: do NOT exchange them via public channels, do NOT commit them into GitHub, and do NOT paste them into AI tools or search engines!
* Step 4 of the tutorial has you edit the sample project's code. If you get a 'didn't respond in time' error when testing your bot, perhaps it is because there's no response to the '/challenge' command in your project code?
* Remember that your team only needs one deployment environment (screenshot that it works).
* Feel free to use AI tools as a tutor or source for debugging any issues that come up.
* You should consider your fork to be a 'hard fork' -- that is, I do not expect (or want...) you to create a pull request merging your group's code into the class's default code. You will be taking a very basic shell and heading in your own independent direction from the starting point I provide.
* I am unlikely to be able to help you troubleshoot the particulars of your computer: my daily use machines all run Linux, and I only use Windows and MacOS for gaming and streaming shows. If you have limited familiarity with your operating system, don't have administrator access to your operating system, or have run into problems in CSS classes before in dealing with your computer, try using a Docker image from the CSS Remote Linux Lab: https://csswiki.uwb.edu/css-linux-lab-docker-image/

==== Bot Project Task #3 ====
;Task: Version 1.1 of your bot
;Due: Friday, October 17, 11:59 p.m. Pacific time
;Deliverables: You are done with task 3 if you have each completed at least one of the user stories supplied by Dr. Champion for your first sprint and successfully deployed the updated bot to your deployment environment for Dr. Champion to review. Tag the code so that it is clear which version is 1.1.
;Turn in: A screenshot of version 1.1 of your bot in action. 

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

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

==== Bot Project Task #4 ====
;Task: Analyze the architecture of your assigned bot
;Due: Friday, October 24, 11:59 p.m. Pacific time.
;Deliverables: You are done with Task 4 if your group has written an architectural guide and added it to your main repository on GitHub. All group members should have made at least one substantive commit to the guide to receive credit and include a diagram explaining how pieces connect to one another.
;Turn in: No need to turn in something for this; Dr. Champion should be able to grade your work right out of GitHub.

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

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

==== Bot Project Task #5 ====
;Task: Identify bugs and technical debt in your assigned bot
;Due: Friday, October 31, 11:59 p.m. Pacific time
;Deliverables: You are done with Task 5 if you have conducted an analysis of limitations and weaknesses in your assigned bot by (1) publishing a report to the main repository and (2) creating user stories drawing from both the problems you've found and any new ideas for improving your bot that arise through this process.
; Turn in: No artifact turn-in required, Professor Champion will grade the state of your repository and project board.

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

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

==== Bot Project Task #6 ====
;Task: Release version 2.0
;Due: November 21 (Friday), 11:59 p.m. Seattle time.
;Deliverables: You are done with Task 6 if you have each completed at least one user story from your second sprint and deployed version 2 to your production environment for Professor Champion to review. Tag the code so that it is clear which version is 2.0.
;Turn in: A screenshot of version 2.0 of your bot in action. 

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

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

==== Bot Project Task #7 ====
;Task: Release version 2.1
;Due: Thursday, December 11, 11:59 p.m. Pacific Time (Note that this is AFTER the demo because you will be incorporating feedback from the demo.)
;Deliverables: You are done with Task 7 if you have each completed at least one user story from your third sprint and deployed version 2.1 to your production environment for Professor Champion to review. Tag the code so that it is clear which version is 2.1.
;Turn In: Screenshots of each new feature added for v2.1. (This is during Finals Week, so a live demo for grading is not possible)

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

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

==== Demonstration of Bot 2.0 ====

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

===== Pre-made Demos =====

Task: Record a pre-made demo of your bot (about 2 minutes).
;Due: Monday, November 24th, 11:59 p.m.
;Deliverables: Each group member will record their own screencapture video of the bot in action with a voiceover.
;Turn In: a video upload to canvas (one per student).

===== Live Demos =====

Task: Conduct a live demo of your bot
;Due: In class on Tuesday, November 25th.
;Deliverables: During your 5-minute slot, show off what your bot can do.
;Turn In: no artifact -- just be present and prepared.

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

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

===== Bot Feedback =====

Task: give feedback to each group
;Due: Monday, December 1, 11:59 p.m.
;Deliverables: a short paragraph of highly specific feedback; grading will be according to my detailed rubric for giving feedback in brief
;Turn In: a text submission on Canvas

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

==== Reflection on Software Engineering and the Bot Project ====

See the [[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 800-1200 words. Under 800 is unlikely to achieve the depth I am seeking here, and over 1200 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 case discussion: 50%
* Sprint 1: 10%
* Sprint 2: 15%
* Sprint 3: 15%
* Presentation (Demo and Feedback): 5%
* Reflection: 5%

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

Standup participation is equivalent to answering one question in class. You can also receive credit for serving as scrum master (that is, taking extra effort to remove blockers on behalf of your groupmates issues shared in standup). If you take on scrum master work after a standup, document this and point it out to me when it occurs. Scrum master for a standup is equivalent to answering one additional 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, but there is no substitute for the synchronous and timely participation in a standup. If you miss standup, the self-balancing approach I use to randomize who answers questions will mean that you are more likely to be called on in subsequent classes.

'''Grade Questions'''
Everyone makes mistakes and I want to fix mine as quickly as possible. If you have questions about a grade, book a private timeslot on my calendar within 2 weeks of the grade being released. In a grade consultation session, I will ask you to take the lead: show me in specific detail how your work fulfills the rubric for the assignment type 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, and I don't recommend it. Instead, come to class prepared and do all the work on schedule.

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

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

If you experience a severe or extraordinary interruption to your ability to complete class work in a timely manner, I expect to follow [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.