CPSC 480-010 Software Engineering (SE) Fall 2026

Archive

• Week 3 Class 6 Thu Sep 10 Posted: Sep 10

  Announcements:

  • Similar Action Words

    Many action words are similar in meaning, but can vary in specificity or in details that they imply.

    Word 1	Word 2	Explanation
    Delete	Remove	"Delete" often implies a permanent action, while "Remove" can be less final or reversible
    Approve	Accept	"Approve" sounds authoritative, while "Accept" is more general
    Invite	Connect	"Invite" is very specific, suggesting a request for participation, whereas "Connect" is broader
    Create	Add	"Create" is making something new, whereas "Add" can mean including something that already exists
    Subscribe	Register	"Subscribe" is ongoing engagement, while "Register" is often a one-time action
    Approve	Validate	"Approve" is a decision or permission, while "Validate" suggests checking or confirming correctness
    Merge	Link	"Merge" is combining into one, whereas "Link" connects them without combining
    Submit	Send	"Submit" is submission to a process, while "Send" is transferring information
    Stop	Pause	"Stop" is final, while "Pause" is temporary
    Cancel	Stop	"Cancel" is preventing something from starting or finishing, whereas "Stop" is halting an ongoing action

    Note that the customer may not realize the difference between these terms, and say one when they mean the other.

  • Exercise 11: GitHub Username GitHub Classroom is no more. Instead, we are using Classroom 50. The process for allowing you to create a repository has changed and is as follows: 1) Add you to the UACPSC GitHub Organization, and 2) Add you to the roster for the course. To do so, I need your GitHub Username. If you don't provide it, you won't be able to do the projects and some exercises.

    The title of this exercise is a link to the form where you can enter your GitHub Username.

    Once I add you to the roster, you will receive an invitation to join the UACPSC GitHub Organization. You will need to join in order to create repositories. Note that this differs from the GitHub Classroom process of the past.

    Due Friday, Sep 11 by 9 am.

  • GitHub Authentication

  Class

  • Project 1: Requirements Report
  • HFSD Chapter 3
  • Exercise 12: Team User Story Estimates

  Unless stated otherwise, all exercises are due by 4 pm on Fri Sep 11

• Project 1: Requirements Report Posted: Sep 10

  Project 1 is due Monday, September 21 at 11:59:59 pm, in the file Requirements.md in a GitHub Organization UACPSC repository. You will need a GitHub account, give me your GitHub Username, and accept the invitation to join the GitHub organization UACPSC. Once you are all setup, an invitation link to create the repository is in Brightspace.

  Description

  At your place of work, you need to submit a formal report describing the project's current state. Write a report of your individual and team activities, including these primary sections:

  1. User Stories

  User Stories with title, description, estimate, and space for priority

  This will be shown to the customer. This section should not contain any information that a customer should not see.

  2. General Process

  Details of the overall process and procedure that created the Estimates

  This will be shown to the customer, so only data on the User Story cards from section 1 should be shown.

  3. Background Data

  Details on spread, assumptions, issues, etc.

  How did the team interaction work, and what did and did not work well

  This will not be shown to the customer. It is for your supervisor.

  In other words, the report describes all the work and processes followed while creating the user stories and their estimates. The details of the general process and the general observations in Section 3 are in the form of a narrative, i.e., describe what you did, how you did it, and the result, ordered by time. The report's tone is professional, with a clear, consistent presentation.

  The team created the User Stories and Estimates, but this report is an individual project. In your account, make changes to User Stories if they do not follow the guidelines given in the book. These changes are especially crucial for the Title and the Description. Split User Stories if the Estimate is too large. Explain any changes in your report.

  Content Notes

  • Identify yourself clearly at the top of the page with your name, email, team name, and section
  • Do not address me at the top of the page
  • Do not sign it at the bottom

  Format

  The report uses plain-text formatting syntax Markdown. Markdown is an almost universal format for text formatting in software development. Due to its direct conversion to HTML, Markdown has replaced HTML and other plain-text formatting languages in SE. It has become so popular that it is a new document type in OneDrive.

  • While Markdown does allow using HTML, do not use any HTML in this report
  • The entire report must be in a single, self-contained file: Requirements.md
  • The report is to look good both as raw Markdown and as a web page in GitHub
  • Plain text (no .pdf, .doc, .docx, etc.)
  • UTF–8 encoding, Note: An ASCII document is a UTF–8 document
  • The file, like all text and source-code files, should end in a newline
  • Do not use any unnecessary multiple-blank lines

  Creating the Report

  You will use git to work on your report. Assuming a username of jdoe@uakron.edu, the steps are as follows:

  1. Create your project repository using the link in Brightspace
  2. Copy the URL from your project page
  3. Clone your repository, e.g., jdoe@uakron.edu
  4. Move to your repository directory:
  5. Edit your document. Any text editor will do. E.g., add the title.
  6. Commit your change with a reason for your change: Commit messages start with a verb, e.g., Add, Remove, Change, Fix, Reformat, etc. Follow the style given in this example: Capitalized verb, no period.
  7. View your current commits:
  8. Push your commits to GitHub:
  9. Verify that your changes appear in GitHub
  10. Repeat steps 5-9 for each change.

  Note: All commits must have non-blank commit messages. Any non-blank commit messages will not be accepted, leading to a 0 on the entire project.

  GitHub Codespace

  A GitHub Codespace is available for this project. See the guide GitHub Codespaces.

  Final Check

  After you have committed your final change to the project, you must run your report through a report check to see if it follows many of the Markdown requirements of the project. To do so, create a GitHub Codespace for the project. When in there, enter the command:

  You should see a clean report. If it finds anything, fix it and rerun the checkmd command.

  The checkmd is a custom command created for this project to verify specific Markdown requirements. A clean run does not mean you have nothing wrong with your project.

  Final Submission Requirement

  Upload an terminal session of your report successfully passing the checkmd program.

  To demonstrate this, you will record a terminal session using asciinema. It records the commands you enter and the output the command produces. asciinema is already installed in the GitHub Codespaces image. You can also install asciinema on Linux/WSL/macOS.

  asciinema is relatively straightforward to use.

  You can play, pause, skip, etc. You can also copy the commands as text. Note that the replay even includes your pauses and any delay as the command is run.

  At the end of the terminal session, asciinema will show a URL. Anybody can use this URL to view the session. This is what you will submit for the exercise to the link in the exercise title. The URL should not contain "connect" or be a local file. Test your URL in a browser; an incorrect URL will receive a 0.

  Submit the URL via this form: Project 1

  Score

  The report content, format, and involvement in team activities are all considered for your score.

  Think carefully about how you present the report, including using Markdown. Remember, the User Stories form an unordered set, not an ordered list.

• Exercise 12: Team User Story Estimates Posted: Sep 10

  Start by reviewing your user stories, particularly the titles. Titles that do not have an action term, or have a poor action term, will be counted off on your score for this exercise.

  As a team, create estimates for the user stories by using the planning poker procedure described on pages 48-49 of the book.

  When the team reaches a consensus for the estimate, place the estimate at the bottom left of the User Story as indicated by the example, e.g., "Estimate: 1 day" or "Estimate: 3 days".

  Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:

  • Title of the user story
  • Any questions on or confusions with the user story
  • Any assumptions that you made
  • Any interesting assumptions that other team members made
  • The spread of estimates, indicating which one is yours. Be very careful with this, and note that a spread is on a number line.
  • The estimate, which is a team consensus (if the team was able to reach one in this round)

  If the team is not able to come to a consensus, table that User Story and go on to another one.

  The notes are due by the end of class. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).

  The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements. Also, you may think of additional user stories. Be sure to add them.

• Week 3 Class 5 Tue Sep 08 Posted: Sep 08

  After Class

  • Exercise 11: GitHub Username GitHub Classroom is no more. Instead, we are using Classroom 50. The process for allowing you to create a repository has changed and is as follows: 1) Add you to the UACPSC GitHub Organization, and 2) Add you to the roster for the course. To do so, I need your GitHub Username. If you don't provide it, you won't be able to do the projects and some exercises.

    The title of this exercise is a link to the form where you can enter your GitHub Username.

    I am posting this early since the deadline is earlier than normal. Due Friday, Sep 11 by 9 am.

  Announcements:

  • Team Exercises & Feedback Each team member gets individual feedback on the team exercises. This includes the work the team did as a whole, as well as your individual contributions. Feedback from the previous team exercise often relates to the current team exercise. Therefore, I am requiring you to view your feedback from the last team exercise via the Assignments page. Failure to do so will result in a large penalty to your exercise score. I suggest that the team remind each other about this at the start of the team meeting.
  • Guide: User Story Title Candidates Feedback

  • Action-Oriented Titles

    The primary goal of user stories is to capture a specific need or goal of a user in the context of software development. It's about "what the user wants to do" or "achieve" with the software.

    Benefits of Action-Oriented Titles:

    • Clarity Action-oriented titles make it clear what the expected outcome or behavior of the system should be
    • Focus on Value Emphasizing actions reminds the team to focus on delivering value and functionality rather than just creating artifacts
    • Facilitates Testing It is easier to derive test cases from action-oriented stories

  • User Story Titles and the Number Grammatical Category

    Strongly consider using a title with a singular noun for a user story, instead of a title with a plural noun, because it emphasizes the atomic nature of the action.

    Plural	Singular
    Upload Documents	Upload a Document
    Send Messages	Send a Message
    Add Products to Cart	Add a Product to the Cart
    Register for Events	Register for an Event
    View Notifications	View a Notification
    Search for Jobs	Search for a Job

    In general, user stories with singular titles are going to be easier to implement. There can be exceptions, as "View Notifications" may be simpler than "View a Notification" due to not having to select just one.

    The most important aspect is clarity and understanding. If "Purchase Clothes" effectively communicates the intent without ambiguity and your team finds it more natural, it's also acceptable. The choice between singular and plural should ultimately be guided by what best serves the clarity and focus of the story in your context.

  • Development Environment: Git Setup by next class.

  Class

  • HFSD Chapter 2
  • Exercise 9: HFSD Chapter 2 Crossword
  • HFSD Chapter 3
  • Exercise 10: Team User Stories II

  Unless stated otherwise, all exercises are due by 4 pm on Wed Sep 09

• Exercise 10: Team User Stories II Posted: Sep 08

  

  Your team is to correct the current user stories and increase the number of user stories. Very carefully go over your user titles and descriptions. Add more user stories and see what you are missing.

  The number of user stories per teams was 7, 9, 11, 12, 16, 16, 16, 17, and 27(!). Twelve and under are far too few. Greatly increase the number.

  Remember to split any user stories that you can. Apply the "and" rule.

  • I want a lot of user stories. Do not make any judgments on whether they are worthwhile or not. Generate as many as you can
  • The User Stories do not belong to an individual team member. They belong to the team. So feel free to make changes to stories, even if you are not the original author.
  • For this assignment, no User Story should have a title that includes "Login" or similar terms. Assume that they have already logged in or (much better) do not have to log in.
  • You have not performed an estimation process. Do not fill in the estimate with some guess or random number.

  In addition to the team work of extracting user stories from the app description, each team member will turn in to Brightspace individual notes that includes:

  • The total number of user stories
  • The titles of at least five user stories. Just state them. No order required.

  The individual notes are due by the end of class uploaded to Brightspace. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).

  Do not upload a photo of all your user stories This will result in a very low score for the exercise. Follow the directions for the individual notes.

• Week 2 Class 4 Thu Sep 03 Posted: Sep 03

  Announcements:

  • Exercise 3: App Idea The feedback on Tuesday for this exercise included "If you fail to fix your issues or view your feedback by 3 pm on Wed Sep 02 I will change your score to a 0". Viewing feedback on an assignment is part of the exercise and project process. If you did not fix your issues or view the feedback, I changed your score to a 0.
  • Data Format Example ADA Title II → WCAG 2.1 AA (or better)

  Class

  • HFSD Chapter 2

  • Exercise 7: HFSD Chapter 2 p42 User Story Interview

    • Be sure to save your response
    • You cannot go back and edit your response
    • The number correct is your score out of 10

  • Exercise 8: Team User Stories

    • Note that almost all Team Exercises will have individual notes due by the end of class.

  Unless stated otherwise, all exercises are due by 4 pm on Fri Sep 04

• Exercise 8: Team User Stories Posted: Sep 03

  

  Each Team is assigned a separate App with the description in Brightspace.

  As a Team, create as many User Stories as you can for that app from the app description. For now, this is just the Title and the Description. The Title is just an action that a user can perform. The Description is from 1 to 3 sentences that describes what that action is. Follow the examples given in the book.

  The User Stories are written on the provided index cards. I will provide a folder for you to put the cards in as I will collect the cards at the end of class.

  • I want a lot of user stories. Do not make any judgments on whether they are worthwhile or not. Do not stop at 6 or some specific number. Generate as many unique user stories as you can.
  • You do not "own" a user story. The user story is part of the project. If you leave the project, the user stories do not go with you.
  • For any assignment in this class, no user story should have a title that includes "Login" or any similar terms. Assume that they have already logged in or (much better) do not have to log in.

  In addition to the team work of extracting user stories from the app description, each team member will turn in to Brightspace separate, individual notes that include:

  • The total number of user stories created
  • The titles of at least 3 user stories

  The individual notes are due by the end of class uploaded to Brightspace. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).

• Week 2 Class 3 Tue Sep 01 Posted: Sep 01

  Announcements:

  • Exercise 3: App Idea I posted scores and feedback in Brightspace

    • "Do not identify yourself in the description"
    • "Submit via Brightspace in PDF form" Word documents are not PDFs

    View your feedback even if you got a 10 / 10. In some cases, a 10/10 does not mean there was nothing wrong.

    Fix any issues that I identified.

    If you fail to fix your issues or view your feedback by 4 pm on Wed Sep 02 I will change your score to a 0

    Note: This "fix your issues and get full points" is not the norm for the exercises and assignments in the course

  Class

  • HFSD Chapter 1

  • Exercise 5: HFSD Chapter 1 Crossword

    • Print using browser (not a screenshot). If a screenshot or a scan, you will receive a 0.
    • Include a timestamp with Headers and Footers (Chrome: More settings/Options; Safari: Safari/Print headers and footers)
  • HFSD Chapter 2
  • Exercise 6: Teams

  Unless stated otherwise, all exercises are due by 4 pm on Wed Sep 02

• Exercise 6: Teams Posted: Sep 01

  Form a team of 4 members. The final team composition is at the discretion of the instructor.

  After forming a team, your team needs to decide on a name from the following choices:

  • Three Stooges (Moe, Larry, Curly, Shemp, Curly Joe)
  • Marx Brothers (Chico, Harpo, Groucho, Gummo, Zeppo)
  • Star Wars Characters

  Pick at least 4 names.

  Send Dr. Collard and Mr. Cowan an email with the following:

  • Subject is CPSC480-010 Team
  • CC all members of the team using their UA email address
  • An attachment file, members.csv, in the CSV (Comma-Separated Values) format. Use the following as an example:

  
  Firstname,Lastname,Email,Section,Team
  John,Doe,johndoe@uakron.edu,010,Harpo
  Jane,Doe,janedoe@uakron.edu,010,Harpo
  Brian,Doe,briandoe@uakron.edu,010,Harpo
  Suzy,Doe,suzydoe@uakron.edu,010,Harpo
  
  

  • The body of the email is a list of requested team names in priority order, e.g.,

  
  Harpo
  Moe
  Yoda
  Zeppo
  
  

  The purpose of a team is not just to divide the work but also to meet a required level of quality. All members of the team must check any team assignment in this course. You, as a team, are responsible for these directions. Any emails sent as part of an assignment (including exercises) must have the correct subject, CC list, and contents. Exercises are not accepted and do not receive points if they do not have the proper form and content.

  The exercise is due by the end of class.

• Week 1 Class 2 Thu Aug 27 Posted: Aug 27

  Announcements:

  • Scores I posted the feedback and scores in Brightspace for Exercises 1 & 2

  • Syllabus Missed section on prerequisites.

    Prerequisites: Minimum C- in CPSC 210 Computer Science II

    Since the prerequisite course is in C++, we will also use C++.

  • Survey Results
  • Notes The class notes have a bunch of default and custom hotkeys. Type a "?" to see the help.

  Class

  • Notes: Context

  • Exercise 3: App Idea - Submit via Brightspace in PDF. Due by 4 pm on Mon Aug 31

    All applications start with an idea or a need. As a user, write a description of an application. The description should include who would use it and its features. The application can be one that you create yourself or an existing program.

    Guidelines:

    • The description must be at least 350 words long
    • Include a name for the app at the top
    • Do not identify yourself in the description
    • Assume this is a smartphone app
    • The description should be of the what not the how. Do not include any discussion of programming languages, libraries to use, or software design. Do not talk about how easy or difficult it would be to create the app. Do not describe the screens, views, or user interaction.
    • If the application already exists, be creative with your name and description

    Comments:

    • This is not the place if you have a great app idea. Your app idea may be shared with others or discussed (anonymously) with the entire class.
    • This is not the app that you or your future team will work on.
  • Notes: Roots
  • HFSD: Chapter 1
  • Exercise 4: HFSD Chapter 1 Sharpen Your Pencil Completed during class.

  Unless stated otherwise, all exercises are due by 4 pm on Fri Aug 28

• Week 1 Class 1 Tue Aug 25 Posted: Aug 25

  Announcements

  • Syllabus The syllabus is available via a link on the main page. It is via Simple Syllabus and you must be logged into UA to view the full contents. The course description does not reflect the last changes, and should be:

  A comprehensive overview of all phases of software development, including requirements, analysis, design, implementation, testing and validation, release, maintenance, and evolution, focusing on agile methodologies.

  • GitHub We use GitHub and GitHub Classroom in the class to manage documents and source code for projects, exercises, and examples. You are required to have a GitHub account. Optionally, you can apply for the Student Github Developer Pack and get a free GitHub Pro account. To apply, your account email can be a school account or a personal account if you upload documents to prove your current enrollment status.
  • O'Reilly Online Learning The course textbooks are available in O'Reilly Online Learning. You do not have to be on the campus network (e.g., via VPN) to access O'Reilly Online Learning. To access, click the "Institution not listed?" link below the dropdown and enter your UA email. You will then create an account and use that account from now on. For more information: Library LibGuide

  Exercises

  • Exercise 1: SE Survey

  • Exercise 2: Software Development Diagram

    Draw the Software Development Diagram that I present in class. Upload a PDF or JPG through Brightspace.

  • Notes: Context

  • For next class: Read Chapter 1 of the HFSD (Head First Software Development) book.

  All exercises are due by 4 pm on Wed Aug 26

• Welcome Posted: Aug 21

  Greetings and welcome to CPSC 480 Software Engineering (SE) section 010 for Fall 2026.

  • Survey The first exercise is to fill out the class survey. The survey is due after our first class meeting, but you can complete it before.
  • Syllabus The syllabus is available via a link on the main page. It is via Simple Syllabus and you must be logged into UA to view the full contents. The course description does not reflect the last changes, and should be A comprehensive overview of all phases of software development, including requirements, analysis, design, implementation, testing and validation, release, maintenance, and evolution, focusing on agile methodologies.
  • Textbook The course has two textbooks. We start with the Head First Software Development (HFSD), available from Safari Books Online via a link at the bottom of the main course page.
  • GitHub In the class, we use GitHub and a GitHub Organization to manage documents and source code for projects and examples. You are required to have a GitHub account. The account email (not necessarily the account name) should be your @uakron.edu email address. If it is, you can apply for the Student Github Developer Pack and get a free GitHub Pro account.

  See you on Tuesday, Aug 25 at 12:15 - 1:30 pm in Arts & Sciences (CAS) room 136