CPSC 480 Software Engineering (SE) Fall 2023

News

---

• Week 5 Class 9 Tue Sep 26 Posted: Sep 26

  Announcements:

  • Tasks do not have names as titles. They are numbered.
  • Tasks have a (numbered) title, a description, and an (eventual) estimate. It is essential in software development to use proper terminology as much as possible.
  • Only estimates obtained by a team consensus using a planning poker process will be put on tasks (just like with user stories). From now on, any assignment or answer with an estimate not obtained via this process will receive a 0. This can be an exercise, a project, or a test question.
  • Tasks are not the process a user would go through. They are the parts of the implementation of the code.

  • Tasks should be brief. For one thing, they need to fit on a post-it note. Secondly, that extra detail does not help; you would never have enough.

  • Project 1: Requirements Report Due 11:59:59 pm Thursday, Sep 28

  Class

  • HFSD Chapter 4
  • HFSD Chapter 5
  • Exercise 18: Team User Story Estimates IV

  Unless stated otherwise, all exercises are due by 3:30 pm on Wed Sep 27

• Exercise 18: Team User Story Estimates IV Posted: Sep 25

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

  First, pick a user story that you have an estimates. Estimate each task for that user story. Indicate if the sum of the task estimates agrees with the previous user story estimate. Update the user story estimate if needed.

  When the team reaches a consensus for the estimate, place the estimate at the bottom of the User Story on a separate line, 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
  • The final estimate, which is a team consensus (if the team was able to reach one in this round)

  If the team cannot reach a consensus, table that User Story and go on to another one.

  Modify the above when you estimate a task instead of a user story.

  The notes are due by the end of class. They can be a PDF (print to file from a computing device) or a JPG (picture taken via phone). The notes are for today only. Do not start with the notes from the previous team meeting.

  The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements.

• Project 1: Requirements Report Posted: Sep 19

  Project 1 is due 11:59:59 pm Thursday, Sep 28, in the file Requirements.md in a GitHub Classroom repository. You will need a GitHub account. Once you have an account, an invitation link to create the repository is on the Brightspace course page.

  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:

  • 1. User Stories
    • User Stories with title, description, estimate, and space for priority
    • This will be shown to the customer
  • 2. General Process
    • Details of the process and procedure that created the Estimates
    • This will be shown to the customer, so only data on the User Story cards should be mentioned.
  • 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, all the work and processes followed while creating the user stories and their estimates. The details of the process and procedure and the general observations 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.

  Format

  • The report is in the plain-text formatting syntax Markdown. Markdown is an almost universal format for text formatting in software development. Due to its direct mapping to/from HTML, Markdown has replaced HTML and other plain-text formatting languages in SE.
  • 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
  • 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

  Score

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

  Think very carefully about the presentation of the report, including how you are using Markdown. Remember, the User Stories are an unordered set not an ordered list.

Archive