480-010 SE News Archive

No.	Due Date	Total Rules Implemented	Exercise Feedback
1	Monday, Nov 3 11:59:59 pm	1	43
	Stop Wait until I provide feedback on your initial workflow by giving you a score for the corresponding exercise. If you don't see a comment, I have not examined your first commit. If you are waiting to continue, send me an email.
2	Wednesday, Nov 5 10:00:00 pm	3
3	Thursday, Nov 6 10:00:00 pm	4
4	Friday, Nov 7 10:00:00 pm	5
5	Monday, Nov 10 10:00:00 pm	7
6	Tuesday, Nov 11 10:00:00 pm	8
7	Wednesday, Nov 12 10:00:00 pm	9
8	Thursday, Nov 13 10:00:00 pm	10
9	Friday, Nov 14 10:00:00 pm	11
	Monday, Nov 18 11:59:59 pm	All rules and all error messages

Project

The input for a source-code static analysis tool can come from multiple sources, including individual files, e.g., main.cpp, directories of source-code files, e.g., src/, source-code archives, e.g., project.tar.gz, file.zip, and standard input, i.e., stdin, e.g., std::cin. In addition, solitary files and source-code archives can include a URL, e.g., https://mlcollard.net/fragment.cpp

To perform the code analysis, the source code is wrapped in a single XML element with metadata about the source code, including filename, programming language, URL, hash, LOC (lines of code), and timestamp. For the source code:

the resulting XML is:

Note: Scroll to see all the attributes.

The attribute hash is of the source and is a SHA1 160-bit (20 bytes) represented in 40 hex characters, which is what Git uses. The xmlns:code="http://mlcollard.net/code" is not an attribute but an XML namespace declaration, handled automatically by XMLWrapper.

The general attribute rules are:

The order of the attributes in your output must follow the order above.
If the value for an attribute is empty, the attribute is not displayed

The attribute's variety of input sources and program options follows the Rules stated below.

Assignment

Implement the following rules following a Test-Driven Development (TDD) approach. Write a test in CodeAnalysisTest.cpp, implement the minimal code necessary to get it working in CodeAnalysis.cpp, refactor/clean up the code to make it clear and logical, and then commit with an appropriate commit message.

All commits must result in a program that compiles and passes all tests. This means you must successfully compile and pass the test program before a commit. Any commit that does not build will result in a 0 for that step, and every commit will be checked.

The code to implement is in the function formatAnalysisXML().
Do not change or create tests for the function filenameToLanguage().
Do not create any new functions.
Using libraries or including files beyond those already defined is unnecessary and strictly forbidden.

Rules

The following rules are unordered. Do not refer to them by number.

The minimum LOC is 0. If the option loc is non-negative, add the attribute loc.
If you cannot figure out the attribute language based on any other rule, use the default language.
When the option hash is not empty, use it for the attribute hash.
When the source url is not empty, use it for the attribute url.
When used, the option url has priority over the source url for the attribute url.
The option language has priority over any other way of determining the attribute language.
The option filename has priority over any other way of determining the attribute filename.
For a non-archive source-code file, the file extension of the disk filename determines the language, e.g., for the disk filename main.cpp, the language is C++. Use the provided function, filenameToLanguage(), to convert from a filename to a language for the attribute language.
For a file in a source-code archive, the file extension of the entry filename determines the language, e.g., for the entry filename main.cpp, the language is C++. Use the provided function, filenameToLanguage(), to convert from a filename to a language for the attribute language.
For a source-code archive, use the entry filename instead of the disk filename for the attribute filename.
For a non-archive source-code file use the disk filename for the attribute filename.
For standard input (i.e., std::cin) of non-archive source code, the disk filename is a single dash "-" and the entry filename is the literal string "data". In this case, you must use the option filename for the attribute filename.
For standard input (i.e., std::cin) of a source-code archive, the disk filename is a single dash "-". In this case, use the entry filename for the attribute filename.
When the timestamp is not empty, use it for the attribute timestamp.

Error Handling

All error messages are written to standard error (i.e., std::cerr) on a separate output line, and the function should return an empty string.

If the file extension is used to determine the language, and there is no mapping for that language, output the error message “Extension not supported”
When the input is from standard input, and a language cannot be determined, output the error message “Using stdin requires a declared language”

Workflow

The workflow for implementing one rule:

Add a single new test case for a single specific rule in the test program CodeAnalysisTest.cpp
Successfully compile and build
Run the test program and verify that the test case fails
Add the implementation only for the new test case in the file CodeAnalysis.cpp
Successfully compile and build
Run the test program and verify that all tests pass, including the new test case
Refactor the test and the added code
Successfully compile and build
Run the test program and verify that all tests still pass, including the new test case
Commit with the appropriate commit message

Refactoring Guidelines

All implementation should result in code that is as clean and clear as possible. For this case:

Output of a particular attribute must occur only once in the code.
Ideally, each rule implementation should only require one additional if-statement.
Prefer simple conditions over complex conditions.
Prefer initialization and if-then over if-then-else.
Separate the logic of calculating an attribute value from the output of the attribute value.
Initialize variables on declaration instead of declaring and then initializing.
Prefer std::string_view to std::string.
Instead of comparing strings to "", use the empty() method.

Evaluation Environment

The project is built and graded in a Docker container running srcml/codespaces, which is the same environment as GitHub Codespaces for this project. It is based on Ubuntu 24.04 and uses the GCC compiler.

On macOS, clang is the default compiler and the one you want to use in most cases. This should not cause a problem with this program. However, before you commit, I recommend ensuring your code can build and pass the tests with GCC and the default compiler, clang.

Add GCC via homebrew:

brew install gcc

The preset macos-gcc (in the file CMakePresets.json) provides settings to compile with GCC:

cmake .. --preset macos-gcc

This preset only appears in macOS and not in Linux or Windows.

To return to using clang:

cmake .. --fresh

Instead of flipping back and forth in the same build directory, use two build directories, one for clang and one for GCC. Be sure to build and test in both build directories before you commit. Note It might seem like a pain to have two build directories, but it is not uncommon in real software development and is a good skill to have.

Grading

Your score will depend on the following:

Meeting the deadlines.
Following the TDD process. This must be reflected in your commit history, both when commits are made and the commit messages.
Successful implementation of the rules.
Following the commit message guidelines.
Coding style, including use of if-statements. The function logic should be as simple as possible. Pay attention to the coding style criteria given in class.

Week 10 Class 18 Tue Oct 28 Posted: Oct 28

Announcements
- Special Office Hours Today 10:30 - 11:30 am, 3:15 - 4:15 pm. Make up for shortened Office Hours on Thursday.
- Exercise 36: AddTest Feedback in the repository in Feedback.md in the branch feedback
Class
- HFSD Chapter 8
- Test Directory Structure Comparison
- Exercise 41: sortTDD
  
  Code along in class (or later on) to the sortTDD example. The GitHub Classroom link is in Brightspace.
  
  The TDD workflow for this code is:
  1. Run all existing tests on the current code and make sure they pass
  2. Add a single new test case for a single specific rule in the test program sortTest.cpp
  3. Successfully compile and build
  4. Run the test program and verify that the test case fails (red)
  5. Add the implementation only for the new test case in the file sort.cpp
  6. Successfully compile and build
  7. Run the test program and verify that all tests pass, including the new test case (green)
  8. Refactor (if needed) the test and the added code
  9. Successfully compile and build
  10. Run the test program and verify that all tests still pass, including the new test case (refactor)
  11. Commit with a commit message about the added functionality
  Class example: sort-tdd-010
  - As suggested by Claude (Anthropic, 2025):
    
    The goal is the simplest implementation that could work, not the silliest
  - The commit message is about the functionality, not the test case. It should not mention the test. We assume that all functionality added has a test case.
  - There is a commit that you do not see:
- Exercise 39: HFSD Chapter 8 Crossword Due Friday, Oct 31
- Exercise 40: Team Code Coverage II
  - View the feedback for Exercise 38: Team Code Coverage. If you do not view the feedback via the Assignments page, you will get no credit for Exercise 40.
  - Using the feedback, fix/redo any parts that were not correct.
  - Finish up the Exercise 38: Team Code Coverage.
  - Your submitted report should not have any previous incorrect parts.
  As with almost all Team exercises, you must upload your work by the end of class.
Unless stated otherwise, all exercises are due by 3 pm on Wed Oct 29
Week 9 Class 17 Thu Oct 23 Posted: Oct 23

Announcements
- Office Hours For today, Office Hours are 10:30 - 10:45 am and 3:15 - 4:15 pm
- Midterm I posted scores and the graded exam in Brightspace Assignments.
  
  I am solely responsible for grading the midterm. If you have any inquiries, feel free to email or visit during my office hours. I do not respond to exam-related queries in the classroom right before or after class.
  
  Note: In the Final Exam, failure to answer the question in the designated place (Questions 4-10) will result in a score of 0 for that question.
- Midterm General notes:
  - Planning is not design. Design is software design. And by software design, I mean what classes, methods, source-code file structure, APIs used, etc.
  - Iteration planning is part of requirements
  - Requirements, design (see previous), code, and test are part of every iteration
  - Once we have an iteration plan, we begin the current iteration. During the current iteration we do nothing for future iterations.
  - Iteration plans are revised at the start of every iteration
  - "Good-enough design" is not "good-enough software". "Perfect design" must meet requirements, but then all software must meet requirements no matter what the design.
- Professional CMake: A Practical Guide by Craig Scott is the best book on CMake for developers. Besides just covering the CMake features, it also has sections in each chapter with good practices and practical advice. One of the best books of its kind. It was a textbook for CPSC 489-010 T: DevOps in Spring 2024.
  
  The first 5 chapters are a free download.
  
  So take a look for any questions on cmake.
- Exercise 37: Team Assert Tests
  
  dotProduct()
  - LOC is a software term for Lines of Code. It is a number. It is not the line numbers, and it is definitely not the code. LOC is an initialism. Like MPG, CPU, or RPM we always use the abbreviation.
  - It is impossible for a single test case to have 100% code coverage for the function dotProduct()
  - It is impossible for the "happy path" test case to only execute 6 or 7 lines of code
  - It is impossible to execute a line with a return in one of the preconditions and execute the last return in the function
Class
- Exercise 36: AddTest
  
  I did not mention this, so I am extending the due date.
  
  Fix the code so that both tests pass. Make sure to commit this separately.
  
  Then, add another single unit test following the style and formatting of the previous unit tests.
  
  Add the unit test to the single testfile testAdd.cpp. There is no need to create new files. If you did not add your test to the testAdd.cpp, do so now.
  
  Make sure it passes all the tests before you commit.
  
  A GitHub Classroom link for addTest is on Brightspace.
- srcML Testing parser testfile, libsrcml testfile, client testfile
  
  So three different parts of testing. But that is not all. There are tests to make sure the installers (Debian packages, rpm's, Windows installers) all work. And tests for any wrappers for libsrcml, e.g., pylibsrcml.
- HFSD Chapter 8
- Exercise 38: Team Code Coverage
  - To replace the original Makefile with CMake, the repository has a pull request:
    
    Accept it at GitHub:
    
    If you have problems with this, let me know and I can accept the pull request for your team.
    
    After the pull request is merged, you will have to git pull to see it in your repository clone.
  - One person cannot commit twice in a row.
  - The assignment is setup for GitHub Codespaces. You are welcome to try on macOS or in Linux (including WSL), but there is no guarantee that it will be setup properly without installing additional packages. If you have an issue on your local machine, turn to GitHub Codespaces.
  As always with Team exercises, due by the end of class.
Unless stated otherwise, all exercises are due by 3 pm on Fri Oct 24
Exercise 38: Team Code Coverage Posted: Oct 23
First, as a team, review the test cases and the code to determine if you achieved 100% code coverage and whether any test cases are not unique and cover the same code. Do not spend much time on this, as you pretty much said so with your previous exercise result.

The following assumes you are in your build directory.

Generate a Code Coverage Report

The tool gcov can, when used with code compiled with the appropriate flags, produce a report that shows exactly how many times each line of code is called during a run of the program. We could use this to determine where our program is taking the most time and perhaps optimize the program. For our purposes today, we can also use it to obtain code coverage. So, we want to run the gcov program with our test program and see the code coverage of the function dotProduct() in the file dotProduct.cpp .

To produce the gcov report, do the following:
1. Clean your build
2. Run cmake to add the option --coverage to the flags provided to the compiler: The CMake variable CMAKE_CXX_FLAGS contains the options passed to the compiler, and CMAKE_EXE_LINKER_FLAGS contains the options passed to the linker. The CMake configuration sets them for things such as Debug and Release builds. The CMake variables CMAKE_CXX_FLAGS_INIT and CMAKE_EXE_LINKER_FLAGS_INIT are the starting values before the CMake configuration sets them.
3. Run cmake so that make will output the commands it is executing (instead of hiding them from you): The CMake variable CMAKE_MAKE_VERBOSE controls whether make shows the commands it uses to build the program. Note: ninja will not work here. This is one exception to ninja being a drop-in replacement for make. Note that cmake caches its settings. So once you have this configured, you can run CMake again and it will still have these values. They are stored in the file CMakeCache.txt.
4. Build the program and observe the commands. You should see the flag --coverage. It will occur on every compile and link command. Record in your notes the command for the compile up to and including the --coverage option.
5. Turn off CMAKE_VERBOSE_MAKEFILE as it is annoying getting that much output with every make command:
6. Run the test program. Do this only once.
7. This run of the program should produce a file with the extension .gcda. The one you are interested in is dotProduct.cpp.gcda. CMake has an extensive directory structure for the object code, and the .gcda file is with the object code.
8. Now that you have found the dotProduct.cpp.gcda we must run it through gcov to get the report. Carefully view the output of the program to find where dotProduct.cpp is and the line that starts with Lines executed:. You can safely rerun this command. You will then see how much code coverage your test program produced. Record in your notes this percentage. You should find a file dotProduct.cpp.gcov in your build directory.
9. If you want to rerun the test program, you must delete the .gcda and .gcno files. A command to do this is (I strongly recommend copy and paste):
Code Coverage Results

View the file dotProduct.cpp.gcov in an editor. You will see lines such as:

Columns are separated by ":". Column 2 is the line number, and Column 3 is the source code. Column 1 is the number of times that line of code was executed, or a - if it is not an executable line (i.e., comment or whitespace). If you see a #####, that means that that line of code was never executed. So, therefore, you do not have 100% code coverage.

Automation

Correctly rerunning all of the above commands is repetitive and prone to mistakes. So let's automate it by taking the above lines and making them targets in our CMake. Add the following code at the end of your CMakeLists.txt file.

Commit this change to the repository with the commit message:

Any time you make changes to the cmake file CMakeLists.txt, rerun cmake:

Now, the sequence to run the coverage for the tests is the following:

Improving the Code Coverage

To fix this problem, you will have to change the file dotProduct.cpp. Look carefully at the lines of code that were not executed, any conditional statements that had to be true to reach that unexecuted line, and your test cases.

The change to dotProduct.cpp is to rearrange some lines. Make this change, build the program, run the test program, and make sure the tests still pass. If the tests all pass, commit the change to the file dotProduct.cpp:

Now, rerun the coverage using our new make targets. Continue making changes to your test cases until you get 100% code coverage. Record in your notes any additional test cases.

Further Automation

This sequence is more complex than it needs to be:

If the build file ran the target coverage-clean before every test, then we would not have to remember to do so. Any knowledge we can put into the build file makes everything easier to repeat. So change (do not just add this code) the test target in the file CMakeLists.txt so that it also DEPENDS on the target coverage-clean:

Since CMakeLists.txt changed, rerun cmake.

Now, the new sequence of commands is:

An even further automation is to automatically run the target test whenever you run the target coverage-report. So, running a new report is a single command. See if you can get this working.

Commit these automation changes to the repository:

Test Cases

Using the coverage, find the percentage of the code in dotProduct.cpp covered by each test case. Do this by commenting out all but one test case at a time and then running a coverage report. Record in your notes the new percentages and how they compare to what you manually calculated.
Week 9 Class 16 Tue Oct 21 Posted: Oct 21

After Class
- Midterm I posted scores and the graded exam in Brightspace Assignments.
  
  The score does not include the extra credit. That will be added later.
Class
- HFSD Chapter 7
- Exercise 35: HFSD Chapter 7 Crossword
- Guide: assert() and Unit Testing
  
  add-test-010
  
  A GitHub Classroom link for AddTest is on Brightspace.
- Exercise 36: AddTest
  
  Fix the code so that both tests pass. Make sure to commit this separately.
  
  Then, add another single unit test following the style and formatting of the previous unit tests.
  
  Make sure it passes all the tests before you commit.
  
  A GitHub Classroom link for addTest is on Brightspace.
- Exercise 37: Team Assert Tests
Unless stated otherwise, all exercises are due by 3 pm on Wed Oct 22
Exercise 37: Team Assert Tests Posted: Oct 21
The project, Vector Angle, calculates the degree angle between two vectors. It uses the function dotProduct(). It also includes a test program dotProductTest.cpp.

As you recall, white-box testing is testing (creating test cases) that knows the structure of the code because it knows the implementation. The test program dotProductTest.cpp includes a single test case using a separate block and an assert().

Your assignment is to add test cases to the file dotProductTest.cpp and get the tests to run successfully.

The repository for this assignment is a GitHub Classroom Group Repository. That means there is one repo per team. Have one person create the Team in GitHub Classroom; the rest can join afterward.

First, build the program:

Then, run the program:

The test program is a separate executable, dotProductTest. To run the test program, there is a target, test. So run the test program:

For this assignment, add tests so that when the complete test program is run, all of the code in dotProduct() is run at least once. This would be 100% code coverage.

The workflow is:
- Pull commits so that you start with the most recent version of the files.
- Add a test case to dotProductTest.cpp that executes at least one line of code that was not executed using the previous test cases.
- Build the program and deal with any syntax errors.
- Run the test program and see if it passes. If it does not, then your test case is likely incorrect.
- Once all tests pass, commit the change using the appropriate commit message.
- Push the commit and verify that the new test case appears on GitHub.
Keep in mind the following:
- Each commit can only add one test
- The commit message must be: "Add test …" where "…" is filled in appropriately. For the first test case already in the test program, the commit was:
- No extra test cases are allowed. Do not add a test case covering the same code as another test case.
- Follow exactly the programming style of the first test case. This includes indentation, formatting, use of whitespace, and blank lines.
- You will have to push, i.e., git push for the other team members to see your test case.
I encourage as many team members as possible to commit a test case. If using GitHub Codespaces, each team member has their own codespace. After a team member has entered a test case, the rest can use a git pull.

Add test cases one at a time to prevent merge issues.

Each team member must submit notes, including for each test case (not just their own):
- Parameter values used along with the expected answer
- LOC (Lines of Code) each test case individually covers. This is a number, not the actual lines. This would be in the function dotProduct() and does not include empty lines or comment lines.
- The percentage achieved of the total lines of code in the function dotProduct() by this test case
The notes and commits of each team member are due by the end of the class, along with the test cases. Your score is based on the notes and commits in the team repository.
Week 8 Class 16 Thu Oct 16 Posted: Oct 16

Announcements
- Project 2 Feedback on your calculations is in Brightspace. This is not the entire grade or feedback that we will provide later. If your feedback was not "Iteration capacity calculation appears correct", I strongly suggest that you figure out what is wrong before the Midterm Exam. You are not allowed to exceed the iteration capacity.
Midterm Exam In our regular classroom and at our regular time.
Week 8 Class 15 Tue Oct 14 Posted: Oct 14

After Class
- Project 2 Feedback on your calculations is in Brightspace. This is not the entire grade or feedback that we will provide later. If your feedback was not "Iteration capacity calculation appears correct", I strongly suggest that you figure out what is wrong before the Midterm Exam. You are not allowed to exceed the iteration capacity.
Announcements
- Office Hours For today, Office Hours are 10:30 - 10:45 am and 3:15 - 4:15 pm
- Project 2 The checkmd required a file called Requirements.md. To use this with IterationPlan.md, we needed to remove this restriction from checkmd.
  
  This changed checkmd is now in the image mlcollard/checkmd, which you get when you run a GitHub Codespace. If you have an existing GitHub Codespace for Project 2, you will have to create a new codespace to get this change.
- Project 2 Keep in mind the following:
  - Each plan includes all user stories
  - Carefully check your calculations, including the numbers you are using
  - The unit of granularity for an iteration plan is an iteration, not day-by-day
  - Do not assign work to each developer
- Project 2 Grading I will post some type of preliminary feedback on your plans by end-of-day on Wednesday. See the "After Class" on Wednesday for details.
- Midterm Exam
- Exercise 33: Team Text Match
  
  In your repository the branch feedback in the file Feedback.md is a Claude (LLM) analysis of the team history for Exercise 33: Team Text Match. I suggest viewing it at GitHub.
  
  Some observations regarding team collaboration and outcomes:
  - All team members should have a basic understanding of the technology used. In this case, for building programs: compiling, linking, options, etc. For Make, how to write rules. Some research might be needed, and while some team members may know more about particular points than others, everyone must have a fundamental understanding.
  - All changes must be verified by any means necessary. Many commits included modifications that would cause an error when make is run. Not every team member did this.
  - It was necessary to coordinate who was doing what. The team was in person at the same time, so this should have been straightforward. Consider what would happen if the team were distributed across different work schedules.
  - Allowing the team to only work on the program sequentially wastes ^(n-1)/_n of the potential. There was no reason why the two executables, textmatch and regexCountTest, couldn't be worked on in parallel. Declarative languages are easier to work on independently than other types of languages due to simpler structures. E.g., make is easier to work on independently than C++.
  - The team cannot afford even one member who makes unverified commits, submits changes that aren't aligned with other work, or has limited foundational knowledge.
Class
- Make Prerequisites
  
  Makefile
  
  Make prerequisite graph for srcComplexity:
- HFSD Chapter 7
- Exercise 34: Team Text Match II
  - build-files-010
  - GNU Make
  - Make Rule Introduction What a rule looks like
  - Automatic Variables including $@, $<, and $^
Exercise 34: Team Text Match II Posted: Oct 14
In your repository the branch feedback in the file Feedback.md is a Claude (LLM) analysis of the team history for Exercise 33: Team Text Match. I suggest viewing it at GitHub.

Read over the analysis and think about what can be improved, not only about your current version of the code, but also about your process. Even if your process worked and you did well, consider how you can parallelize your development (instead of waiting while someone else makes changes).

Follow the instructions for Exercise 33: Team Text Match

The targets from last time were: make clean, make run, make test

Once you have all those targets implemented, implement the following:
- Add the target manpage, i.e., make manpage, that creates a man page. This was added to the build-files-010. Note that my example also added a comment. The manpage will be named textmatch.1. It is generated from the markdown file textmatch.1.md. This conversion uses the command lowdown. It is not installed in your GitHub Codespace. However, you do have the permissions to install it. First, update
  
  Then install the package:
  
  If you are in WSL, you need to use sudo before each command. On macOS, brew install lowdown
- Add the target man, i.e., make man, that views the created manpage. This was also added to the build-files-010, and it has its own comment.
- Add a comment to the textmatch executable and its object files.
- Add a comment to the regexCountTest.cpp executable and its object files.
- Add a comment to the clean target
- Add a comment to the run target
As before, this is due by the end of class. No commits outside of class.
Exercise 23: Project 1 "Fix spelling of "calendar" Posted: Oct 10
This exercise is optional. However, completing this exercise will add points to your Project 1 score.

The exercise is due by Tuesday, Oct 8 at 11:59:59 pm EDT.

In your repository for the Requirements Report is the file Corrected.md. This is an edited version of what you submitted with fixes and improvements to the writing.

To see the difference between these two files, you can use the diff command:

The diff utility is line-oriented. Since many of your lines are quite long (the lines are wrapped when you view them), this may be difficult to read. You can also use the wdiff command:

The codespace for Project 1 has diff and wdiff installed. You will have to start a new codespace to use wdiff. If you want to use wdiff outside of a codespace, install on WSL/Linux apt-get update; apt-get install wdiff, and on macOS brew install wdiff.

Your workflow must be the following:
1. Examine the remaining differences between your original report and the corrected one using diff or wdiff.
2. Select one individual correction
3. Make the correction
4. Commit the correction using an appropriate commit message
5. Push the commit to GitHub
6. Verify at GitHub that the commit is there and the correction is made
Each correction must be a contiguous change. That means that each commit only contains one correction. Practically, this means that each correction/commit will be on a single line.

To get credit, your resulting Requirements.md file must be exactly the same as the Corrected.md file. You will reach this stage when diff shows no differences.

The git commit messages must be in the proper form, such as:
- Fix spelling in story title
- Fix spelling of "calendar"
- Capitalize story title
- Simplify description
- Fix spacing in description
- Add missing article in story title
- Add missing article in general process
- Simplify sentence in user story title
The commit messages must following good git commit message guidelines:
- Use the imperative mood in the subject line, e.g., Fix, not Fixed, Fixing
- Capitalize the subject line, e.g., Fix, not fix
- Do not end the subject line with a period, e.g., Fix spelling of "calendar", not Fix spelling of "calendar".
The score on this exercise will be 0 if the commit messages do not follow the above guidelines, or there is no effort to use an appropriate commit message.

Note:

There will be a lot of commits, so you want to be efficient creating them. After you do the first few corrections, you can push to GitHub and verify at GitHub periodically and not every time. And, to save time with entering commands, bring up previous commands in a shell using the up arrow ⇧ or Ctrl + P, and edit the git commit messages if necessary.
Week 7 Class 14 Thu Oct 09 Posted: Oct 09

After Class
- Project 2 The checkmd required a file called Requirements.md. To use this with IterationPlan.md, we needed to remove this restriction from checkmd.
  
  This changed checkmd is now in the image mlcollard/checkmd, which you get when you run a GitHub Codespace. If you have an existing GitHub Codespace for Project 2, you will have to create a new codespace to get this change.
Announcements
- Office Hours Regular times today 10:30 - 11:30 am and 3:15 - 4:15 pm
- Project 1
  
  Grades in Brightspace right before class. Feedback in the file Feedback.md in the branch feedback
- Project 2 Due Tuesday, Oct 14 at 11:59:59 pm
- Midterm Exam Thursday, October 16
Class
- CMake
  
  CMakeLists.txt CMake file for the Build Files example
  
  To download to your repository:
  
  Guide: Using CMake
- Guide: Build Configurations
  - How many GCC optimization levels are there?
  - MSVC optimizations /O options (Optimize code)
- Exercise 32: Build Configurations
  
  Fill out the Build Configurations table so that it reaches 82,944 different configurations.
- Exercise 33: Team Text Match
Exercise 33: Team Text Match Posted: Oct 09
The utility textmatch finds the number of times a regular expression occurs in a file. The repository for this exercise is a GitHub Classroom Group Repository. That means there is one repo per team. Have one person create the Team in GitHub Classroom; the rest can join the team afterwards.

The last person who worked on it was an intern from another university. They entered the build commands in a shell every time they built the program. Of course, you and your team know better, so your team will implement the Makefile for this project.

Every team member must do one of the following to receive credit:
- Make commits to the Makefile
- If you do not have a computer and cannot commit during the team meeting time, then hand write the Makefile on paper and upload to Brightspace by the end of class.
Restrictions:
- Add to the Makefile step-by-step following the general procedure used in the Build Files example
- Do not change any other file
- Do not use any of the automatic variables until after all the base functionality is complete
- The number of commits per team member (for those making commits) must be within 1 of the other team members, i.e., as equal a number of commits as possible
- An individual team member cannot have two commits in a row
- No commits can be made after class ends
As your team members make commits, you will have to update your working copy. Use the command:

Note that your team does not share a GitHub Codespace. All of them are different. You will not see other team members changes until you pull.
Midterm Exam Posted: Oct 09
The Midterm Exam is Thursday, October 16, during our regular class time and classroom. It covers Chapters 1 - 6.5 of the Head First Software Development book, plus notes and in-class examples.
- Big Bang approach to development - description, the path it takes, and disadvantages
- Iterative approach to development - description, the path it takes, and advantages
- Role of the customer/client
- User Stories - all parts, description, creation, valid user story titles
- Estimates and the Estimation Process, including all details of planning poker
- Iteration and deadline planning
- Utopian vs. Real-World days
- Velocity - description, standard rate, what does it mean if velocity is higher or lower
- Big Board - basics of what it shows and how developers use it
- Good-enough design, SRP, DRY
- Version control - jobs that it does, commit messages, branches (specific git information not on this midterm)
- Role and importance of build artifacts (code, configuration, tools), the general purpose of make and cmake; Given a Makefile, what would happen with specific targets.
The exam has various problem types, including short answers, definitions, comparisons, creation of user stories, and planning. The question may require you to:
- Explain a process or terminology of a process
- Answer specific questions about parts of the process. E.g., "Explain why the recommendation is to come up with user stories whose estimates are 15 or less."
- Explain what process and activities you would follow for a particular scenario
It is a good idea to review the "Dumb Questions" and the answers.

The questions are based on what we covered in the book, the exercises, and the projects. If I did not cover it in class, it is not on the exam.

A calculator is not needed for any required math and, therefore, not permitted.
Week 7 Class 13 Tue Oct 07 Posted: Oct 07

Before Class
- Exercise 26: Makefile
  
  Feedback is in the file Report1.md in the branch feedback in your Build Files repository.
  
  You can view this at GitHub. Look where it indicates the current branch:
  
  Select the branch feedback and you will see the file Report1.md.
  
  We will continue to add to this code in another exercise. If you have lots of problems, then get my current version:
  
  build-files-010
  
  Then put that into your Makefile and save it. Finally, commit that to your repository with the following command:
  
  Do not deviate from this commit message as it will cause problems when I grade it.
Announcements
- Office Hours Regular hours 10:30 - 11:30 am. Advising Hours (by appointment) are from 3:15 - 4:15 pm.
- Project 1
- Project 2: Iteration Plan
  
  Each student must get their own priorities. Do not reuse the ones from the Team Exercises.
- Team Meeting There is no Team Meeting today
Class
- HFSD 6.5
- Make
  
  build-files-010
  - GNU Make
  - Make Rule Introduction What a rule looks like
  - Special Note: recipes are indented using a tab character, not spaces. Using spaces (or an editor that expands tabs to spaces) will result in an invalid Makefile.
  - Automatic Variables including $@, $<, and $^
  - NMake Microsoft's version of Make
  - srcML Playground Generate new srcML of source code, input format for srccomplexity
- Exercise 30: Makefile II
  
  This is a continuation of Exercise 26: Makefile. Use the same repository as before. Code along and make the same commits with the same commit messages as I do in class.
  
  I suggest you use GitHub Codespaces as all necessary packages are installed.
- Exercise 27: HFSD Chapter 6.5 Crossword
- Exercise 28: Make Crossword
- Notes: Build Files
  
  CMakeLists.txt CMake file for the Build Files example
  
  To download to your repository:
- Exercise 31: Build Files Crossword
Unless stated otherwise, all exercises are due by 3 pm on Wed Oct 08
Week 6 Class 12 Thu Oct 02 Posted: Oct 02

Before Class

If you haven't already created the GitHub Classroom repository for "Build Files" you should do so before class. Check Brightspace for the GitHub Classroom Build Files Invitation Link. You can also set up a GitHub Codespace for the project, as it takes some time to start up initially and when restarting.

Announcements
- Office Hours For today, Office Hours are 10:30 - 10:45 am and 3:15 - 4:15 pm. Remember that I am available by appointment.
- Project 1
- Project 2: Iteration Plan
- Post Page The main course page is getting quite long. A reminder that the title of each post is a link to a separate page of that post.
- Version Control We have only covered a high-level view of version control. During the rest of the semester, we will cover it in much more detail as part of dedicated notes and the overall workflow.
Class
- HFSD 6.5
- Make
  
  build-files-010
  - GNU Make
  - Make Rule Introduction What a rule looks like
  - Special Note: recipes are indented using a tab character, not spaces. Using spaces (or an editor that expands tabs to spaces) will result in an invalid Makefile.
  - Automatic Variables including $@, $<, and $^
  - NMake Microsoft's version of Make
  - srcML Playground Generate new srcML of source code, input format for srccomplexity
- Exercise 26: Makefile
  
  There is a GitHub Classroom Invitation Link in Brightspace for this exercise. The name is "Build Files".
  
  Code along and make the same commits with the same commit messages as I do in class.
  
  I suggest you use GitHub Codespaces as all necessary packages are installed.
- Exercise 27: HFSD Chapter 6.5 Crossword Due after next class
- Exercise 28: Make Crossword Due after next class
- Exercise 29: Team Iteration II
Unless stated otherwise, all exercises are due by 3 pm on Mon Oct 06

Project 2: Iteration Plan Posted: Oct 02

Project 2 is due on Tuesday, Oct 14 at 11:59:59 pm. A GitHub Classroom invitation link is on the Brightspace course page.

For Project 2, take all the user stories from Project 1 and create a series of iteration plans.

Use the examples in the book to show which parts of the user story you should show in your iteration plan (e.g., do not restate descriptions in the plans). Also, clearly state the entire new iteration plan for each plan, not just the changes. However, make sure to thoroughly discuss what the change was and what effect it had.

This is an individual project. Each member of a team has different user-story priorities. To get individual priorities for Project 2, select the number of user stories:

Put these in the Priority field in the order in which you listed the user stories. In the report, do not discuss how you generated your report's priorities, i.e., pretend that the customer gave them.

The following plans may require you to add additional user stories. This violates our rule that only the development team can create estimates. However, as part of the exercise, put in an estimate.

Each plan is a point in time. For each plan, show the entire iteration plan, including the iterations already completed.

Plan	Events
1	Create an initial iteration plan: 2 Weeks (14 calendar days) iteration, 2 developers, 0.6 velocity
2	The customer adds two new user stories of the highest priority at the end of the first iteration. For the two new user stories, one is a new feature, and one is an emergency. Create a non-trivial estimate (i.e., an estimate that makes the planning interesting) for these new user stories.
3	A user story with a non-trivial estimate takes twice as long. Assume this occurred right before the last iteration.
4	At the beginning of the last iteration of your current plan, the other developer leaves for another project, and it is up to you to finish the project.

After the plans, create a section with all of your user stories, including their titles, descriptions, estimates, and priorities. You will need estimates for all of your user stories.

Regarding the format, GitHub Codespaces, checkmd, and a Final Check with an asciinema session, all of those requirements of Project 1 are also in effect for Project 2.

Submit the URL via this form: Project 2

Exercise 29: Team Iteration II Posted: Oct 02
Your team completed the first iteration. Despite inexperience with determining estimates, you did complete the all the planned user stories.

For some of the remaining user stories, not part of the first iteration, the customer updated the priorities of 4 user stories. Get new priorities for these user stories:

User Stories:

Now, design a second iteration. Use the principles in the book to decide which of the remaining user stories belong in the second iteration.

Individually, each team member will turn in to Brightspace notes with the following:
- Details of the calculation of the capacity of the iteration, i.e., how many days of work can be accomplished
- Set of user stories in the revised first iteration with title, estimate, and priority
- Set of user stories in the second iteration with title, estimate, and priority
- Any observations
Do not assume any dependencies between user stories.

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).

If you finish early, work on real estimates for your user stories.
Week 6 Class 11 Tue Sep 30 Posted: Sep 30

After Class
- Make and Build Files
  
  There is no current exercise for Make using the Build Files GitHub Classroom Invitation Link. We will do this on Thursday.
Announcements
- Career Fair & Class
  
  The career fair is from 10 am to 2 pm. It is 4 hours long, not because students will spend 4 hours attending, but to allow students to fit attendance in between their classes.
  
  Career fair attendance during class time is not an excused absence.
- Office Hours For today, Office Hours are 10:30 - 10:45 am and 3:15 - 4:15 pm.
- UNIX Commands
  
  I occasionally use UNIX commands in a bash shell to perform development tasks or to point out the results of development tasks. Obviously there is git, but there are a lot of other commands that we use. We just saw diff and patch.
  
  I recommend that you keep a list of these commands with the name, short description, and example of using it. These commands will not be on any exam unless I specifically say they are. However, they may be part of a crossword.
Class
- Demo: Patching Linux
  explainshell
- Exercise 23: Patching Linux
  
  Follow along with the Patching Linux demo shown in class. Write the commands in order as they are applied in the demo.
  
  For the URLs, copy and paste, or write a shortened form of the URL.
  
  Upload to Brightspace this list of commands. This can be a text file, or an image of the commands written on paper. This is due by the end of class.
- Notes: Version Control
- Exercise 24: Version Control Overview Crossword II
- HFSD Chapter 6.5
- Make
  
  build-files-010
  - GNU Make
  - Make Rule Introduction What a rule looks like
  - Special Note: recipes are indented using a tab character, not spaces. Using spaces (or an editor that expands tabs to spaces) will result in an invalid Makefile.
  - Automatic Variables including $@, $<, and $^
  - NMake Microsoft's version of Make
  - srcML Playground Generate new srcML of source code, input format for srccomplexity
  There is a GitHub Classroom Invitation Link in Brightspace for this example (and future exercise). The name is "Build Files".
- Exercise 25: Team Iteration
Unless stated otherwise, all exercises are due by 3 pm on Wed Oct 01
Exercise 25: Team Iteration Posted: Sep 30
As a team, create the first iteration of an iteration plan.

Ideally, we would have enough Team Meeting time to estimate all user stories using Planning Poker. However, we do not. To make up for this, I am providing estimates for the rest of your user stories. Enter the following:

Current Maximum User Story Estimate:
Missing User Story Estimates:

Add these estimates to your user story cards.

The other missing item is the priorities. These come from the customer. To get priorities, select the number of user stories:

User Stories:

Add these priorities to your user stories.

You have 1 developer and a one-month iteration with a 70% velocity.

Use the principles in the book to decide which user stories belong in the first iteration.

Individually, each team member will turn in to Brightspace notes with the following:
- Details of the calculation of the capacity of the iteration, i.e., how many days of work can be accomplished
- Set of user stories in the first iteration with title, estimate, and priority
- Any observations
Do not assume any dependencies between user stories.

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).

If you finish early, use planning poker for estimates on the user stories your team did not estimate earlier.
Week 5 Class 10 Thu Sep 25 Posted: Sep 25

After Class
- Career Fair & Class
  
  I fully support students attending the career fair. The career fair will take place from 10 am to 2 pm. It is 4 hours long, not because students will spend 4 hours attending, but to allow students to fit attendance in between their classes.
  
  Career fair attendance during class time is not an excused absence.
Announcements:
- Office Hours Regular hours today 10:30 - 11:30 am and 3:15 - 4:15 pm
- Shell Tab Completion Complete the entry of a file, directory, and sometimes options using the tab key when the prefix is unique
  
  Then hit the tab key to complete the filename.
- Tasks
  - Tasks do not have names as titles. They are numbered.
  - Tasks have a (numbered) title, a description, and an 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).
  - Tasks are not the process a user would go through. They are what the developer would go through. They are different 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 detail.
Class
- HFSD Chapter 6
- Notes: Version Control
- Exercise 21: Version Control Overview 1 Crossword
- Exercise 22: Team Tasks II
Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 26
Exercise 22: Team Tasks II Posted: Sep 25
As a team, take a user story that has an estimate, and create the tasks for that user story. Then, create the estimate for each task by playing planning poker using the procedure described on pages 48-49 of the book. Go through the estimation process at least one time.

When the team reaches a consensus for the estimate, place the estimate at the bottom of the task, 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, task title, and description of the task
- Any questions on or confusions with the user story/task
- 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 task and go on to another one.

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.
Week 5 Class 9 Tue Sep 23 Posted: Sep 23

Announcements:
- Office Hours For today, Office Hours are 10:30 - 10:45 am and 3:15 - 4:15 pm.
- Project 1
- GitHub Codespaces GitHub Codespaces are not shared by multiple GitHub accounts. Your repository is accessible by two GitHub accounts, each of which can create its own codespace. Each account can also have multiple codespaces for the same repository.
Class
- HFSD Chapter 5
- Exercise 19: HFSD Chapter 5 Crossword
- HFSD Chapter 6
- Notes: Version Control
- Exercise 20: Team Tasks
Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 24
Exercise 20: Team Tasks Posted: Sep 23
As a team, take a user story that has an estimate, and create the tasks for that user story. Then, create the estimate for each task by playing planning poker using the procedure described on pages 48-49 of the book. Go through the estimation process at least one time.

When the team reaches a consensus for the estimate, place the estimate at the bottom of the task, 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 and task
- Any questions on or confusions with the user story/task
- Any assumptions that you made
- Any interesting assumptions that other team members made
- The spread of estimates, indicating which one is yours
- The 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 task and go on to another one.

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.
Week 4 Class 8 Thu Sep 18 Posted: Sep 18

Announcements
- Office Hours For both Tuesday this week, Office Hours are 10:30 - 10:45 am and 3:15 - 4:15 pm.
- Resume
  
  If you bring a printed copy of your resume to me during my 3:15 - 5 pm extended Office Hours on Thursday, September 18, I will review it and provide suggestions for improvement.
- Project 1: Requirements Report
  
  Note the change in due date.
  - Include all user stories, even those without estimates. If a user story does not have an estimate, leave the estimate value blank.
  - Project 1 is not a team project. They only thing that you share with your team is the user story cards. Everything else originates from you. Do not set a team template for this.
  - This is a report about the team results and process, not your individual results and process.
  - The first two sections will be shown to the customer. Those sections should only contain information the customer is allowed to see. You will lose a significant number of points if you do not follow this rule.
  - All user stories belong to the team. This is a report of the current state of your team project.
  - There is no "my user story". All user stories belong to the team, actually the customer.
  - The customer is not interested in tasks, only the user stories.
  - The report should be readable and consistent both in markdown and displayed as a web page at GitHub.
- Project 1 asciinema session The asciinema session is after you complete Project 1. Since you are still performing estimation, you are not done with the user stories for Project 1.
  
  So why have some of you submitted your asciinema session?
- Estimates
  - Estimation in software development is not about finding the minimum time it would take you to complete a user story. It's about understanding and predicting the genuine effort required in the context of a 5-day week 50 weeks a year. Remember, an estimate is not a speed challenge but rather a measure of how long it will realistically take to completely implement a user story.
  - Avoid the trap of only considering the quickest or simplest implementation. Proper estimation requires thoughtful consideration of all possible complexities. Moreover, completing a user story quickly doesn't mean the rest of the day is free; there's always another user story waiting. This is not a class assignment or a lab exercise where once you are finished you are done for the day.
  - Refrain from using phrases like "All we have to do …” when discussing software tasks. Such assumptions oversimplify the complexities of coding.
- Exercise 14: Commit to Project 1 Repository
  
  First word of the commit message:
Class
- HFSD Chapter 4
- Exercise 17: HFSD Chapter 4 Crossword
- Exercise 18: Team User Story Estimates II
Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 19
Exercise 18: Team User Story Estimates II Posted: Sep 18
Start by reviewing your user stories, particularly the titles. Titles that do not have an action term, or have a poor action term, will reduce your score on Project 1.

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 4 Class 7 Tue Sep 16 Posted: Sep 16

Announcements:
- Office Hours For both Tuesday and Thursday this week, Office Hours are 10:30 - 10:45 am and 3:15 - 5 pm.
- Resume
  
  If you bring a printed copy of your resume to my office at 3:15 - 5 pm on Tuesday, September 16, or Thursday, September 18, I will review it and provide suggestions for improvement.
- Windows File Explorer & WSL
  
  To open the Windows File Explorer on the current directory in WSL:
  
  The . means the current directory in WSL. You can also open a file explorer.exe Requirements.md. If you open a path it has to be in Linux format, e.g., C:\Users\JohnDoe\Documents would be /mnt/c/Users/JohnDoe/Documents.
- Assumptions
  
  I noticed that many of the assumptions mentioned are about the difficulty of implementation. This is not what the book discusses. Instead, they are assumptions about what the user story means. The only person who can answer those assumptions is the customer.
  
  From now on, label assumptions about the user story as assumptions and assumptions about implementation as implementation.
- Dependencies
  
  I see a lot of user story estimates where the assumptions include the completion of a previous user story. This is a dependency. Avoid dependencies at all costs. For example, Add … does not have to be completed before Delete …. Obviously there will be some dependencies, but they are to be at the user-story level, not the implementation level.
Class
- Creating the Report
- Git Commands The table will expand as we use more commands
- Exercise 14: Commit to Project 1 Repository
  
  Following the procedure given in the assignment and demonstrated in class, contribute at least one commit to the Project 1 repository. This must be a valid and useful commit.
  - Use the git CLI to make the commit. You can do this wherever you have the repository cloned. You can even do this in a GitHub Codespace
  - Good commit messages follow certain patterns, and you need to follow them on all git commits:
    - Start with an action, e.g., Add
    - Capitalize the subject line (the only line we are using)
    - Use the imperative mood, e.g., ~~Added~~, ~~Adding~~, ~~Adds~~, Add
    - Do not end the subject line with a period
  You can see your commit messages with the git log command.
- HFSD Chapter 3
- Exercise 15: HFSD Chapter 3 Crossword
- HFSD Chapter 4
- Exercise 16: Team User Stories III
Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 17
Exercise 16: Team User Stories III Posted: Sep 16
Your management is concerned that your team does not have a complete set of user stories. The first problem is low recall, i.e., the team is not capturing all the user stories the customer needs. The second problem is that without not enough work, the organization will have to ~~let some of the team members go~~ cut everybody's pay.

The customer met with their team and returned with a list of potential user-story titles. These possible new user stories fall into one of the following categories:
- An existing user story
- Not a user story title
- New, but needs to be converted from plural to singular
- New, but needs to be split into multiple stories
- Not part of the description
Each team member will fill out the form for your team:
- Chewbacca
- Gummo
- Harpo
- Shemp
Create a new user story, or multiple user stories, for each of these valid potential user stories. This includes fixing any title issues and adding a description. Also, take this time to fix any existing user stories.

If you have any additional time, then create more estimates. As you did before, keep track of details for the next team meeting when you will submit any estimate details.

There is nothing to upload for this exercise. Complete the provided form.

Week 3 Class 6 Thu Sep 11 Posted: Sep 11

After Class

Announcements:

Office Hours Today 10:30 - 10:45 am, 3:15 - 4:15 pm
2025 CEPS Engineering, Engineering Technology, and Computing Career Fair September 30 (Tuesday) from 10am to 2pm in Student Union. Pre-registration is open through Monday, Sept. 15, at 11:55 pm.

If you bring a printed copy of your resume to me during my Office Hours or Advising Hours on Tuesday, September 16, or Thursday, September 18, I can review it and provide suggestions for improvement.
Exercise 13: Team User Story Estimates

In grading, I did not consider the user story titles. I will do so after the team assignment for today.

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.

GitHub Authentication
Project 1: Requirements Report

Class

Exercise 12: Create Project 1 Repository

Create your Project 1 Repository from GitHub classroom. Log into GitHub, then use the link on Brightspace to create your repository.

As you use the link, it will ask you to select your UA username (email address) from the list. Please do so carefully, and do not select the wrong email.

This is due by 3 pm on Monday, Sep 15
HFSD Chapter 3
Exercise 13: Team User Story Estimates

Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 12

Project 1: Requirements Report Posted: Sep 11
Project 1 is due ~~Monday, September 22~~ Wednesday, September 24 at 11:59:59 pm, 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 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.
- 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 13: Team User Story Estimates Posted: Sep 11
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 09 Posted: Sep 09

Announcements:

Office Hours Extra hour today from 3:15 - 4:15 pm. Reduced hours on Thursday morning due to meeting. Note that I have Office Hours by appointment outside of these times.
Brightspace & Exercises Uploads of assignments to Brightspace may not be available until the end of class, even when the Class Meeting is posted early.
Exercise 7: HFSD Chapter 2 p42 User Story Interview I am not sure I announced it, so it will be due with the rest of the exercises for today.
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.
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 deriving 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

Exercise 9: HFSD Chapter 2 p 47 Cubicle Conversation
HFSD Chapter 2
Exercise 10: HFSD Chapter 2 Crossword
HFSD Chapter 3
Exercise 11: Team User Stories II

Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 10

Exercise 11: Team User Stories II Posted: Sep 09

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 4, 5, 6, 9, 10, 11, 12, 13. Under 9 is way 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 all 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 04 Posted: Sep 04

After Class

I am not sure that I announced Exercise 7: HFSD Chapter 2 p42 User Story Interview, so it will be due after the next class.

If you are reading this and haven't completed it, go ahead and do so.

Announcements:
- Office Hours The 10:30 - 11:30 am Office Hours are only from 10:30 - 10:45 am
- 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 03 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.
- Pattern Recognition
  
  Pattern recognition and adaptation are essential skills in software development. This involves closely following examples while adjusting them to fit specific needs, whether working with APIs, formatting code, handling data, or configuration. Lacking this skill can complicate development, introduce bugs, and waste development time.
  
  For the first team exercise, Exercise 6: Teams, the instructions clearly state to attach a file with the name members.csv. Here is the list of attachment file names I received:
  
  As far as the content of the file:
  
  Correct format:
  
  Missing field name row:
  
  Spaces that are not part of the data:
  
  Quotes everywhere:
  
  Wrong section format:
  
  Very wrong section format:
  
  Duplicate emails:
  
  This is not even mentioning the lack of a EOL at the EOF.
  
  Note For those teams who did not attach the file members.csv, you can make it up by sending me a new email. The contents of members.csv must be exactly the same as the previous attachment.
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 3 pm on Fri Sep 05
Exercise 8: Team User Stories Posted: Sep 04

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 02 Posted: Sep 02

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 3 pm on Wed Sep 03 I will change your score to a 0
- Exercise 4: HFSD Chapter 1 Sharpen Your Pencil - Results
Class
- HFSD Chapter 1
- Exercise 5: HFSD Chapter 1 Crossword
  - Print using browser (not a screenshot)
  - Include a timestamp with Headers and Footers (Chrome: More settings/Options; Safari: Safari/Print headers and footers)
- Exercise 6: Teams
Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 03
Exercise 6: Teams Posted: Sep 02
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. Iddrisu 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 28 Posted: Aug 28

Announcements:
- Scores I posted the feedback and scores in Brightspace for Exercises 1 & 2
- Survey Results
- Notes The class notes have a bunch of default and custom hotkeys. Type a "?" to see a list.
Class
- Notes: Roots
- Exercise 3: App Idea - Submit via Brightspace in PDF form. Due by 3 pm on Mon, Sep 1
  
  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.
- HFSD: Chapter 1
- Exercise 4: HFSD p7 Sharpen Your Pencil Due by 3 pm on Fri, Aug 29
Week 1 Class 1 Tue Aug 26 Posted: Aug 26

Announcements
- Syllabus
- 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 3 pm on Wed Aug 27
Welcome Posted: Aug 20
Greetings and welcome to CPSC 480 Software Engineering (SE) section 010 for Fall 2025.
- Syllabus The draft syllabus for the course is on the main course page. I will finalize the syllabus before our first class meeting.
- 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.
- 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 GitHub Classroom 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 26 at 9:15 - 10:30 am in (CAS) room 134

CPSC 480-010 Software Engineering (SE) Fall 2025

Section 010 TR 9:15 - 10:30 am (CAS) 134

Archive

Branch `main`: Session Testing without DIP

Branch `dip`: Session Testing with DIP

Branch `mock`: Session Testing with Mock Objects

Project

Assignment

Rules

Error Handling

Workflow

Refactoring Guidelines

Evaluation Environment

Grading

Generate a Code Coverage Report

Code Coverage Results

Automation

Improving the Code Coverage

Further Automation

Test Cases

Description

Content Notes

Format

Creating the Report

GitHub Codespace

Final Check

Final Submission Requirement

Score

CPSC 480-010 Software Engineering (SE) Fall 2025

Section 010 TR 9:15 - 10:30 am (CAS) 134

Archive

Branch main: Session Testing without DIP

Branch dip: Session Testing with DIP

Branch mock: Session Testing with Mock Objects

Project

Assignment

Rules

Error Handling

Workflow

Refactoring Guidelines

Evaluation Environment

Grading

Generate a Code Coverage Report

Code Coverage Results

Automation

Improving the Code Coverage

Further Automation

Test Cases

Description

Content Notes

Format

Creating the Report

GitHub Codespace

Final Check

Final Submission Requirement

Score

Branch `main`: Session Testing without DIP

Branch `dip`: Session Testing with DIP

Branch `mock`: Session Testing with Mock Objects