CPSC 480 Software Engineering (SE) Fall 2023

News

---

• Week 14 Class 25 Tue Nov 28 Posted: Nov 28

  Announcements

  • Project 4: Streaming Reminder: Due Friday Dec 15 at Noon

  Class

  • Notes: Waterfall Software Process Models
  • Exercise 55: Waterfall Software Process Models Crossword
  • Notes: Software Engineering Paradigms - Continue
  • Exercise 56: Software Engineering Paradigms II Crossword
  • Notes: Agile Software Process Models
  • Exercise 57: Agile Software Process Models Crossword
  • Notes: Software Evolution

  • Exercise 58: Team Streaming Meeting II

    Have a "standup meeting" with your team. Go over:

    • What did you do previously?
    • What are you going to do next?
    • What (if anything) is holding you up?

    If a team member is going to do something next, make sure it is an issue and that they are assigned to it.

    Upload a text file, PNG, or PDF with a short paragraph describing what you discussed, and possibly accomplished, during your team meeting.

    This is due by the end of class.

  Unless stated otherwise, all exercises are due by 3:30 pm on Wed Nov 29

• Project Streaming Posted: Nov 21

  Your company purchased a streaming video service. The plan is to use this code (and the associated data-mining platform) for a future software product.

  Your team is in charge of the software. The immediate goal is to bring this codebase up to company standards by filling in the (primarily missing) unit test cases and performing refactorings. You are not to add any new features or change the code's behavior in any way, only to improve the design and implementation quality of the current functionality.

  Each team has a GitHub Classroom repository. An invitation link to create the repository is on the Brightspace course page. All work is through the project repository via issues, branches, and pull requests. Discussions will take place via the issue tracking system in GitHub.

  You have the following overall work to do:

  • Create unit test cases. Create an issue in the repository for each set of unit test cases. Then, assign them to a member of the team. Note that you need a complete set of test cases before you perform refactoring on a class.

  • Perform Refactorings Contribute refactorings by creating issues in the repository. These issues must motivate why the refactoring is necessary and include the name of the refactoring.

  • Adaptive Maintenance Current code does not take advantage of the features of C++11. In many ways, these are also refactorings, but there is no standard catalog for them. Treat them as refactorings in terms of issues and branches. You can also take advantage of the features of C++14 and C++17.

  For each of these activities:

  • Team members assign themselves issues from the group repository
  • For each issue, create a topic branch with the number of the issue, e.g., issue1. Work for that issue occurs on that branch.
  • Work from the branch is contributed to the main branch via pull requests. No direct work occurs on the code in the main branch.
  • After you perform a refactoring and pull the changes into the main branch, the associated issue is closed. Also, if the team decides that the refactoring is not a good idea, close the issue.
  • Note that if the refactoring causes methods to be created or removed, the unit test may also need refactoring
  • The existing code's coding style (indentation, use of whitespace) meets the company coding standards, and any changes must preserve the current coding style.

  Notes:

  • Each team member must implement one issue for adding test cases. If there are more test case issues to implement than team members, then a team member may do more than one. If there are more team members than test case issues, two team members can work on the same test file.
  • There is a list of refactorings to perform. There are more than 11, so each team member should do about 3 or 4. Do not do more than that so each team member has enough to do.
  • The Big Refactoring must be completed.
  • The person who creates an issue does not have to be the same as the person who performs the changes.
  • As much as possible, discussion on technical issues is through the issue tracking system of GitHub.
  • Your score on this assignment depends on your contribution, including creating issues and performing refactorings. Therefore, use your own GitHub account to contribute issues, contribute to discussions on issues, and make pull requests.
  • For purposes of grading, do not delete any branches.

  The only allowed changes to the code are:

  • Add test cases
  • Create functions in the test files to make test cases easier to write
  • Apply Fowler refactorings
  • Apply adaptive maintenance changes for C++11, C++14, and C++17.

  Note that you cannot delete any classes. You can, however, add classes.

  Points are deducted from all members of the team for any additional functionality added to the project

  Technical Notes:

  • The only branches that you should have are issue branches and main, and changes must be pulled into the main branch to count for the project
  • The project has CMake build files
  • The project uses an external C++ Testing Framework called Catch2. CMake automatically downloads the file catch.hpp. You can also directly download the file. Do not add the file catch.hpp to your repository.

Archive