CPSC 480-010 Software Engineering (SE) Spring 2023

Archive

• Finals Week

  • Office Hours By appointment only during Finals Week

  • Final Exam Question 1 Take Home

    In your team's GitHub repository for StreamVideo, you will find an analysis of your team's work on the StreamVideo project in the file Report.md. Read over this report.

    Then write an answer to the following:

    What did you learn by performing the team project for StreamVideo, including refactorings, testing, and the overall process of issues, branches, and pull requests? What would you do differently if you had to do it all over again?

    Submit your answer as a PDF to Brightspace. It must be at least 500 words long. The report is due by Fri, May 5 11:59:59 pm.

• Week 15 Class 28 Thu Apr 27 Posted: Apr 27

  Announcements

  • Office Hours By appointment only during Finals Week
  • Finals Week Will post links and any updates to the course page
  • Final Exam
  • Project Streaming
  • Course Evaluations Open through Apr 30

  Class

  • Notes: Use Cases
  • Notes: Process Refactoring
  • Notes: End Notes

  • Exercise 62: Team Use Case Diagram

    As a team, create a Use Case Diagram of your Team Project (the App from the first part of the semester) using yuml.me. Try to include all of the Use Case relationships, include and extend.

    Submit the text of the Use Case Diagram using this form. One entry per team.

  • Exercise 63: Individual Use Case Diagram

    Submit a scan of a hand written use case diagram that is a version of your teams. Include at least 6 different Use Cases in the diagram.

    Submit via Brightspace.

  All exercises are due by 4:30 pm on Fri Apr 28

• Week 15 Class 27 Tue Apr 25 Posted: Apr 25

  Announcements

  • Final Exam
  • Project 3 feedback and scores posted:
    • Overall score and score on each part in Brightspace
    • Report.md in GitHub
    • TDD Report

  Class

  • Notes: SE Code of Ethics
  • Notes: Case Study Dieselgate
  • Exercise 60: SE Code of Ethics Crossword

  • Exercise 61: Team Meeting

    Work as a team on your project.

    There is nothing to submit to receive credit for this exercise.

• Final Exam Posted: Apr 25

  The Final Exam is in our regular classroom Final Exam: May 2, 5:15 - 7:15 pm.

  The first question on the test is a Take Home question. You will answer it online outside of class. I will post the question by Monday of Finals Week.

  You are responsible for what we have covered since the Midterm:

  • Process Models - standard process models, Waterfall, Agile, requirements volatility
  • Software Evolution - greenfield and brownfield development, main conclusions of Lehman's Laws
  • Refactoring - basic definition, terminology, process
  • Code Smells - basic definition, terminology, process
  • TDD - Principles and process
  • Git Workflow - The main git commands, understanding of forks, branches, and pull requests. GitHub issues.
  • Software Lifespan Models - stages and characteristics, viewpoints from time, money (income and expenditures), and career
  • Software Change - types of change, concept location, impact analysis. Be able to identify the maintenance category from a commit message.
  • Software Metrics - Know at least 2 different software metrics
  • Scrum - fundamental steps, terminology, and time limits
  • Use Case and Use Case Diagram - Be able to draw the diagram, and know the difference between Use Case and User Stories
  • SE Code of Ethics - Know the list of the main categories in order

  The exam has various problem types, including short answers, definition, comparison, and application to a code example/scenario.

  If I did not cover it in class, it is not on the exam.

• Week 14 Class 26 Thu Apr 20 Posted: Apr 20

  After Class

  • On the DevOps crossword, the answer to 3 down is "sensitive".

  Special Announcement

  Return to in-person classes on Thursday, Apr 20. See you in our regular classroom.

  Class

  • Notes: Software Metrics II
  • Notes: DevOps
  • Exercise 58: DevOps Crossword

  • Exercise 59: Team Meeting

    Work as a team on your project.

    There is nothing to submit to receive credit for this exercise.

• Week 14 Class 25 Tue Apr 18 Posted: Apr 18

  Special After Class

  Return to in-person classes on Thursday, Apr 20. See you in our regular classroom.

  Special Announcement

  2023 CEPS Design Day on Tuesday, Apr 18 is cancelled, and UA switched to remote learning late Monday night.

  In order to reserve time for a rescheduling of the 2023 CEPS Design Day, we will have class on Tuesday, Apr 18.

  Class will be remote via Teams.

  My Office Hours will remain the same as normal (1 - 2pm and 4:45 - 5:15pm) but will be via Teams.

  Class

  • Note: Software Metrics
  • Note: Software Metrics II

  • Exercise 57: Team Meeting

    Work as a team on your project in the Breakout Rooms. There is one for each team.

    There is nothing to submit to receive credit for this exercise, except to meet in the Breakout Room

• Week 13 Class 24 Thu Apr 13 Posted: Apr 13

  Announcements

  • • 2023 CEPS Design Day on Tuesday, Apr 18

    The Computer Science presentations are from 2 - 4 pm, and I encourage you to attend.

    This time period conflicts with the afternoon CPSC 421-020 OOP and CPSC 480 SE sections, so we will not have a class meeting on Tuesday, Apr 18.

    • 10:45 am - Noon
    • 1 - 1:45 pm
    • 4:15 - 5:15 pm

  Class

  • Note: Scrum
  • Exercise 56: Scrum Crossword
  • Notes: Code Analysis

  • Exercise 55: Team Meeting

    Contribute to the project. This can be:

    • Creating a new issue
    • Improving a current issue
    • Adding to the discussion for an issue
    • Creating a branch for an issue, and making a commit to that branch
    • A commit to a branch
    • Perform a pull from a pull request (if it is ready)

    For a team member to receive credit, contribute to the project, preferably during class time. If you cannot contribute to the project during class, then by the exercise due date.

    Use the form above to describe what contribution you made and provide a link to the contribution in GitHub. You will not receive credit unless you fill out the form.

  All exercises are due by 4:30 pm on Fri Apr 14

• Week 13 Class 23 Tue Apr 11 Posted: Apr 11

  Class

  • Notes: Concept Location
  • Notes: Code Analysis

  • Exercise 54: Team Meeting

    Contribute to the project. This can be:

    • Creating a new issue
    • Improving a current issue
    • Adding to the discussion for an issue
    • Creating a branch for an issue, and making a commit to that branch

    For a team member to receive credit, contribute to the project, preferably during class time. If you cannot contribute to the project during class, then by the exercise due date.

    Use the form above to describe what contribution you made and provide a link to the contribution in GitHub. You will not receive credit unless you fill out the form.

  All exercises are due by 4:30 pm on Wed Apr 12

• Week 12 Class 22 Thu Apr 06 Posted: Apr 06

  Announcements

  • Due date for Project Streaming is Tuesday, April 25.

  Class

  • Notes: Program Comprehension
  • Exercise 50: Program Comprehension Crossword
  • Notes: Software Lifespan Model
  • Exercise 51: Software Lifespan Model Crossword
  • Notes: Concept Location

  • Exercise 52: Rename Method Refactoring & Workflow II

    After seeing the new name, length(), in action, the team has decided that the name of the method should be size(), not length(). Perform a Rename Method refactoring to rename from length to size. Use the procedure Fowler describes and the workflow shown in class, including the issue, branch, and pull request.

  • Exercise 53: Team Meeting

    Create issues for testing.

    For a team member to receive credit, they must create an issue, preferably during class time. If you cannot create an issue during class, then by the exercise due date.

    To receive credit, you must be at the Team Meeting in class.

  All exercises are due by 4:30 pm on Fri Apr 07

• Week 12 Class 21 Tue Apr 04 Posted: Apr 04

  Class

  • Exercise 45: Code Smell Crossword
  • Project Streaming
  • Git Animation - Links on Brightspace
  • Exercise 46: Git Animation Crossword
  • Notes: Software Change

  • Exercise 47: Join Team

    Meet with your team. Make sure everyone present on the team accepts the invitation.

  • Exercise 48: Build StreamVideo

    Create a screencast of you cloning, building, and running the tests for the Streaming Project.

    Upload using the form in the link of the exercise.

  • Exercise 49: Software Change Crossword
  • Notes: Program Comprehension

  All exercises are due by 4:30 pm on Wed Apr 05

• Project Streaming Posted: Apr 03

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

  The project is due by 11:59:59 on Tuesday, Apr 25.

• Week 11 Class 20 Thu Mar 30 Posted: Mar 30

  Class

  • Software Refactoring
  • Exercise 43: Software Refactoring II Crossword

  • Exercise 44: Rename Method Refactoring & Workflow

    Perform a Rename Method refactoring. Use the procedure Fowler describes and the workflow shown in class, including the issue, branch, and pull request.

    A GitHub Classroom link is in Brightspace.

  • Notes: Refactoring Catalog
  • Notes: Code Smells

  All exercises are due by 4:30 pm on Monday, Apr 3.

• Week 11 Class 19 Tue Mar 28 Posted: Mar 28

  Announcements

  • GitHub At the time I write this GitHub is experiencing "degraded performance" with Git Operations. You can check the status of GitHub via the GitHub Current Status.

    In general, this should only effect git pull or git push. A git commit is performed in the local repository (that you cloned). The timestamp on a commit is based on when you made the commit, not when it was pushed.

    Other parts of the status that may be applicable are Pull Requests, Issues, and Codespaces. If you see problems with Pages that means that you can still access the course pages (course pages are hosted in GitHub Pages), but I may not be able to update the pages.

  Class

  • Agile Software Process Models
  • Exercise 40: Agile Software Process Models Crossword

  • Exercise 41: Maintenance Categories

    The quiz at the link in the title has you select, based on a commit message, whether a commit is for an adaptive, corrective, or perfective change.

    Classifying changes into new features or particular maintenance categories based solely on the commit message is inaccurate. Accurately doing so requires considering the code changes (including added code comments), any related issues, and any related discussion to know the reason for the change:

    • To tell the difference between adding a new feature and adaptive maintenance.
    • To tell the difference between a preventive and corrective change.

    In this exercise, all of the commit messages are for commits that are maintenance changes (i.e., not new features). In addition, the only categories considered are corrective, adaptive, and perfective.

    One other consideration is the purpose of the change:

    • Fixes to internal code documentation (e.g., header comments), pure test changes, changes to build files, etc., are perfective maintenance because they do not affect the program's behavior for the user.
    • Fixes to build files are often for new versions of the build tools, e.g., cmake, and are then adaptive maintenance.
    • Removal of code can be perfective maintenance. However, if the code was removed because of a deprecated API, that is adaptive maintenance.
  • Software Refactoring
    • Strongly advise following in the notes so you can compare pre and post
  • Exercise 42: Software Refactoring I Crossword

  All exercises are due by 4:30 pm on Wed Mar 29

• Week 10 Class 18 Thu Mar 16 Posted: Mar 16

  After Class

  • GitHub At the time I write this GitHub is experiencing "degraded performance" with Git Operations. You can check the status of GitHub via the GitHub Current Status.

    In general, this should only effect git pull or git push. A git commit is performed in the local repository (that you cloned). The timestamp on a commit is based on when you made the commit, not when it was pushed.

    Other parts of the status that may be applicable are Pull Requests, Issues, and Codespaces. If you see problems with Pages that means that you can still access the course pages (course pages are hosted in GitHub Pages), but I may not be able to update the pages.

  Announcements

  • To convert from an int to std::string, use std::to_string().

  Class

  • Notes: Software Engineering Paradigms
  • Notes: Waterfall Software Process Models
  • Exercise 36: Waterfall Software Process Models Crossword
  • Exercise 37: Software Engineering Paradigms II Crossword
  • Notes: Software Evolution
  • Exercise 38: Software Evolution Crossword
  • HFSD Chapter 12
  • Exercise 39: HFSD Chapter 12 Crossword

  All exercises are due by 4:30 pm on Monday, Mar 27

• Week 10 Class 17 Tue Mar 14 Posted: Mar 14

  Announcements

  • Midterm

    Midterm scores and feedback are posted in Brightspace:

    • Overall score in Grades under Midterm
    • Copy of your test as a pdf in Assignments under Midterm Feedback
    • Scores and feedback for each question as a pdf in Assignments under Midterm Feedback

  • Exercise 32: CodeAnalysisTDD First Pass

    The first step of the project. Feedback and a score. Fix any problems I mention.

    Some examples of commit messages that do not follow the guidelines, or can be improved:

  Class

  • Exercise 33: HFSD Chapter 10 Crossword
  • HFSD Chapter 11
  • Exercise 34: HFSD Chapter 11 Crossword
  • Notes: Software Engineering Paradigms
  • Notes: Waterfall Software Process Models
  • Exercise 35: Software Engineering Paradigms I Crossword

  All exercises are due by 4:30 pm on Wed Mar 15

• Week 9 Class 16 Thu Mar 09 Posted: Mar 09

  After Class

  • Midterm

    Midterm scores and feedback are posted in Brightspace:

    • Overall score in Grades under Midterm
    • Copy of your test as a pdf in Assignments under Midterm Feedback
    • Scores and feedback for each question as a pdf in Assignments under Midterm Feedback

  Announcements

  • Project 3: TDD First due date changed
  • Git Commit Messages Leaving this up for reference

  Class

  • HFSD Chapter 9
  • Exercise 30: HFSD Chapter 9 Crossword

  • Exercise 31: Git Commands I

    asciinema is a way to record terminal sessions. It records the commands that you enter and the output the command produces. You will use it to record exercises involving git commands.

    After you install asciinema on Linux/WSL/macOS, it is quite straightforward to use.

    You can play, pause, skip, etc. You can also copy the commands as text.

    For this exercise, you will use the GitHub Classroom Git1 invitation link in Brightspace.

    With this repository, performing the following instructions using git. As you enter commands, record your terminal session with asciinema. Commands must be typed with no copy/paste. When completed, save the URL that asciinema gives you and enter it into this form

    1. Show the current status
    2. Show the difference in the working copy
    3. Create the file list.txt, touch list.txt
    4. Add the file list.txt to the staged commits
    5. Show the current status
    6. Show the difference in the working copy
    7. Show the difference of the staged commits
    8. Show the branch name
    9. Create and move to a new branch called issue1
    10. Show the branch name
    11. Append 'a' to the list file, echo "a" >> list.txt
    12. Show the difference in the working copy
    13. Commit all changes in the working copy with the commit message "Add a to the list"
    14. Push the commits to GitHub
    15. Change back to the main branch
    16. Show the difference between the main branch and the issue1 branch
    17. Pull the issue1 commits into the main branch
    18. Show the difference between the main branch and the issue1 branch
    19. Show the current status
    20. Push the commits to GitHub
    21. Show the current status

    Here is a reference to the commands used:

    Description	Command
    Status	git status
    Difference in the working copy	git diff
    Add a file to staged commits	git add <filename>
    Difference of staged commits	git diff --staged
    Push the changes to GitHub	git push
    Current branch	git branch
    Create a branch	git checkout -b <branchname>
    Move to an existing branch	git checkout <branchname>
    Commit all changes in working copy	git commit -am "<commit_message>"
    Commit all staged commits	git commit -m "<commit_message>"
    Pull the changes from another branch	git pull origin <another_branch>
    Difference of two branches	git diff <branch1>..<branch2>

  All exercises are due by 4:30 pm on Fri Mar 10

• Week 9 Class 15 Tue Mar 07 Posted: Mar 07

  Announcements

  • Project 3: TDD
  • Consider using GitHub Codespaces for Project 3

  Class

  • HFSD Chapter 9
  • Git Commit Messages
• Git Commit Messages Posted: Mar 07

  The article How to Write a Git Commit Message has guidance on commit messages in general and Git projects specifically. Especially note the 7 rules. As the writeup mentions, these ideas are not new.

  A message with only a subject line is adequate for our projects. The rules that only concern the subject are:

  • Limit the subject line to 50 characters
  • Capitalize the subject line
  • Do not end the subject line with a period
  • Use the imperative mood in the subject line (command or instruction)

  Make sure to use these guidelines as you implement any projects or exercises.

• Project 3: TDD Posted: Mar 07

  In Project 3: TDD, you will follow a TDD process to implement code submitted via a GitHub Classroom repository. An invitation link to create the repository is on the Brightspace course page.

  Due Dates:

  • By Friday, Mar 10, Monday, Mar 13 11:59:59 pm, create your repository (via GitHub classroom) and make one pass through the TDD workflow (red, green, refactor). Students who miss this deadline will have their overall score for Project 3 reduced by 10 points (one letter grade). I strongly advise that you start right away.
  • The rest of the project is due by 11:59:59 pm on Friday, Mar 17 Monday, Mar 27.

  The input for a (source) code-analysis project is source code that can come from multiple sources, including solitary 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://raw.githubusercontent.com/UAComputerScience/sorttdd-mlcollard/main/sortTest.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, and LOC (lines of code). For the source-code example, the resulting XML has the following attributes:

  Attribute	XML Example
  language	language="C++"
  url	url="http://mlcollard.net/fragment.cpp"
  filename	filename="fragment.cpp"
  LOC	loc="3"
  hash	hash="39dcad4f59855aa76420aa3d69af3d7ba30a91bb"

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

  The programming language is typically determined from the file extension, e.g., .cpp for C++, but exceptions exist. The variety of input sources and program options for the metadata follows the rules stated below.

  Assignment

  Implement the below rules following a Test-Driven Development (TDD) approach. Write a test in CodeAnalysisTest.cpp, and implement the minimal code necessary to get it working in CodeAnalysis.cpp, refactor/clean up the code to make it clear and logical, then commit with an appropriate commit message. You are encouraged to commit more than once per test case, e.g., after entering the minimal code to solve the problem and refactor/clean up the code.

  • The code you have to implement is in the function formatAnalysisXML()
  • You cannot create or use new functions besides the given code.
  • A CMake build is provided.
  • Do not change or create tests for the function filenameToLanguage(), as they are already completed and tested.

  Rules

  • If you cannot figure out the attribute language based on any other rule, use the default language.
  • For a regular file on disk, in most cases, the file extension of the disk filename determines the language, e.g., for main.cpp, the language is C++. Use the provided function, filenameToLanguage(), to convert from a filename to a language for a regular file's attribute language.
  • For a file in a source-code archive, in most cases, 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 file in a source-code archive.
  • The option language has priority over any other way of determining the attribute language.
  • 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.
  • When the option hash is not empty, use it for the attribute hash.
  • The option filename has priority over any other way of determining the attribute filename.
  • For a source-code archive, use the entry filename instead of the disk filename for the attribute filename.
  • For a regular file use the disk filename for the attribute filename.
  • For standard input (i.e., std::cin) of a regular file, 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.
  • The minimum LOC is 0. If the option loc is non-negative, add the attribute loc.

  Error Handling

  All error messages are written to standard error (i.e., std::cerr), 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”

  Grading

  Your score will depend on the following:

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

• Midterm Exam Thu Mar 02 Posted: Mar 02

  Midterm In our regular classroom

  Office Hours from 4:45 - 5:15 pm today are cancelled.

• Week 8 Class 14 Tue Feb 28 Posted: Feb 28

  Announcements

  • Midterm
  • Project 1 Scores in Brightspace, feedback in your GitHub Repository.

  • Project 2 Due date is Wednesday, Mar 1 at 8:00 am EDT.

    On Wednesday, I will provide feedback about your calculations and plans.

    I will accept changes to Project 2 through Friday, Mar 3 at 4:30 pm.

  • Exercises Special due date

  Class

  • HFSD Chapter 8

  • Exercise 27: sortTDD

    Follow along with the TDD process. Commit after every refactoring.

    The GitHub Classroom link is in Brightspace.

    sorttdd-mlcollard

  • Exercise 28: HFSD Chapter 8 Crossword

  • Exercise 29: MockClock

    Follow along with the MockClock example. Commit after every added mock object.

    The GitHub Classroom link is in Brightspace.

    mockobject-mlcollard

  • HFSD Chapter 9

  All exercises are due by 4:30 pm on Monday, Mar 6.

• Week 7 Class 13 Thu Feb 23 Posted: Feb 23

  Announcements

  • Midterm
  • Project 1 Still working on feedback and scores
  • Project 2 Changed due date

  Class

  • HFSD Chapter 7
  • Exercise: 26 HFSD Chapter 7 Crossword
  • HFSD Chapter 8

  All exercises are due by 4:30 pm on Fri Feb 24

• Midterm Posted: Feb 23

  The Midterm Exam is Thursday, Mar 2, and covers Chapters 1 - 7 of the Head First Software Development book, plus my notes on Version Control and Build Files.

  • 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, and descriptions
  • Estimates and the Estimation Process, including 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, tags, branches (specific git information not on this midterm)
  • Role and importance of build artifacts (code, configuration, tools), the general purpose of make and cmake
  • Types of Testing: black box, white box, grey box, whose view they represent and the kinds of things they test for

  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 go over the "Dumb Questions" and the answers.

  Questions are from 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 of the math required, and, therefore, not permitted.

• Week 6 Class 12 Thu Feb 16 Posted: Feb 16

  After Class

  • Office Hours No Office Hours on Tuesday, Feb 21

  Announcements

  • Project 2: Iteration Plan Start early
  • Project 1 Working on feedback and scores. Probably finish on Monday.
  • Exercise 24: Makefile Verify that it builds and that all the targets work. You have an extension until the exercise due date to do that.

  Class

  • HFSD Chapter 6.5
  • Notes: Build Files

  • Exercise 25: CMake

    For this exercise, we will use our existing srcComplexity project where we did the Makefile.

    Implement a CMakeLists.txt to build the project by following along in class, or viewing the commits later on.

    makefile-mlcollard

  • HFSD Chapter 7

  All exercises are due by 4:30 pm on Tuesday, Feb 21

• Week 6 Class 11 Tue Feb 14 Posted: Feb 14

  Announcements

  • Project 2: Iteration Plan

  Class

  • HFSD Chapter 6
  • Notes: Version Control
  • Exercise 23: Version Control Crossword II
  • HFSD Chapter 6.5

  • Exercise 24: Makefile

    Use the GitHub Classroom Makefile Exercise link on Brightspace to create the repository for the srcComplexity program.

    The Makefile is currently empty. Implement a Makefile to build the project by following along in class, or viewing the commits later on.

    makefile-mlcollard

  Unless otherwise indicated, exercises are due by 4:30 pm on Wed Feb 15

• Project 2: Iteration Plan Posted: Feb 10

  Project 2 is due by Friday, Feb 24 8:00 am Wednesday, Mar 1. 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). Also, for each plan, clearly state the entire new iteration 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. See the next section to get individual priorities for Project 2.

  Put these in the Priority field in the order that 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 have you 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 estimation plan, including the iterations already completed.

  Plan 1

  Create an initial iteration plan:

  • 2 Weeks (14 calendar days) iteration
  • 2 developers
  • 0.6 velocity

  Plan 2

  The customer adds two new user stories of the highest priority at the very 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.

  Plan 3

  A user story with a non-trivial estimate is taking twice as long. Assume this occurred right before the last iteration.

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

  Priorities

  To get invididual priorities for Project 2, select the number of user stories:

  User Stories:

  30

  Note: You may get a warning from your browser that the information is not secure. You can safely ignore that. As an alternative, you can directly access this from a command line and copy it directly into the clipboard, e.g., if you have 30 stories.

  On macOS:

  curl http://66.228.46.28/cgi-bin/priority.sh?stories=30 | pbcopy
  

  In WSL:

  curl http://66.228.46.28/cgi-bin/priority.sh?stories=30 | clip.exe
  

  In Linux with xclip installed:

  curl http://66.228.46.28/cgi-bin/priority.sh?stories=30 | xclip
  

• Week 5 Class 10 Thu Feb 09 Posted: Feb 09

  Announcements

  • Project 1: Requirements Report Changed due date

  Class

  • HFSD Chapter 6

  • Notes: Version Control

    hello.cpp

    iostream.patch

  • Exercise 21: Version Control Crossword I

  • Exercise 22: Team Estimates III Due: End of class

  Unless otherwise indicated, exercises are due by 4:30 pm on Fri Feb 10

• Exercise 21: Team Estimates III Posted: Feb 09

  Spend your Team Meeting finishing estimates for the user stories. You will need them for Project 2. You can stop estimating tasks at this point.

  Each team member will turn in to Brightspace a separate document that includes each round of planning poker:

  • Title of the user story
  • The spread of estimates, indicating which one is yours
  • The team consensus (if the team was able to reach one in this round)
  • Any assumptions that you made
  • Any questions or confusions on the user story that is of interest

  I recommend you take notes as you go along. If on paper, do this exercise on a new sheet of paper. The uploaded document can be a PDF or a JPG.

• Week 5 Class 9 Tue Feb 07 Posted: Feb 07

  Announcements

  • Project 1: Requirements Report

    In software, we use a variety of formats, i.e., languages, to define what we intend, and then use tools to generate the result. With traditional programming we use programming languages, e.g., C++, and then use a compiler/linker to build the executable program or runtime. It is very important not only to write the code, but to compile/link the code into an executable, and then to run the result.

    With Markdown we write in a plain-text format. This is then translated into HTML or another form so we can view it. With Markdown documents on GitHub (.md extension), GitHub automatically displays it as a web page. As with source code, we need to make sure that the Markdown that we write looks proper both as raw text and as a web page on GitHub.

  • Crossword Labs had an update in the past couple of days. Printing is much more standard. So now you can both 1) Print using the Print menu item in your browser and 2) Use the Print button

    New Crossword Labs Print Feature

  Class

  • HFSD Chapter 5

  • Exercise 18: What's my purpose? Due: End of class. Put the completed handout in the folder when the team meets.

  • Exercise 19: HFSD Chapter 5 Crossword Due: 4:30 pm on Wed Feb 08

  • Exercise 20: Team Tasks II Due: End of class

  Unless otherwise indicated, exercises are due by 4:30 pm on Wed Feb 08

• Exercise 20: Team Tasks II Posted: Feb 07

  Reminder

  • Every time you look at the set of user stories, you may see improvements. These improvements include wording, grammar, capitalization, terminology, and even if the team should split a user story. The user stories can be updated right up until implementation. So, if you see any improvements, make them.

  Steps

  1. Pick a user story that a team member has tasks for
  2. Write the tasks for that user story on the task cards
  3. Estimate each task using planning poker. Only perform one round for each task

  Perform the above as many times as you can. Each time, use the initial tasks from a different team member.

  Each team member will turn in to Brightspace a separate document that includes each round of planning poker:

  • Title of the user story and task
  • The spread of estimates, indicating which one is yours
  • The team consensus (if the team was able to reach one in this round)
  • If the consensus changes the overall estimate of the user story
  • Any assumptions that you made
  • Any questions or confusions on the user story or task that is of interest

  I recommend you take notes as you go along. If on paper, do this exercise on a new sheet of paper. The uploaded document can be a PDF or a JPG.

• Week 4 Class 8 Thu Feb 02 Posted: Feb 02

  After Class

  • Crosswords

    Crossword Labs had an update in the past couple of days. Printing is much more standard. So now you can

    1. Print using the Print feature in your browser
    2. Use the print button

  Announcements

  • Exercise 14: Requirements Report Repository

    If you did not create your repository in GitHub Classroom for Project 1, then I will assume you will not be working on it, and therefore I can already give you a 0 on the project. It is too late to get credit for the exercise, but if you still want to submit the project later, create your repository in GitHub Classroom.

  • Team Folders Take your graded work from the Team folder during the Team Meeting time. Do not leave it in the folder. If you are working on paper, use a clean sheet of paper for each Team Meeting.

  Class

  • HFSD Chapter 4

  • Exercise 15: HFSD Chapter 4 Crossword

  • Exercise 16: Team Tasks

  • Exercise 17: Individual Tasks

    Divide up the user stories without tasks among all present members of the team.

    For next class, create tasks for each of your user stories. Do this on paper or electronically. Do not write them on the cards until the next class meeting time.

    At no time are you to take home the user story or task cards from the team folder.

    Upload a PDF or PNG to Brightspace.

    This is due by 4:30 pm on Monday, Feb 6

  Unless otherwise indicated, exercises are due by 4:30 pm on Fri Feb 03

• Exercise 16: Team Tasks Posted: Feb 01

  Reminders

  • Every time you look at the set of user stories, you may see improvements. These improvements include wording, grammar, capitalization, terminology, and even if the team should split a user story. The user stories can be updated right up until implementation. So, if you see any improvements, make them.

    In particular, make sure your user story titles are as good as they can be:

    • The title has to complete the sentence "A user should be able to …". Say the title outloud multiple times.
    • I see a lot of missing articles, i.e., "A", "An", "The".
    • Avoid weak words "Info", "Data", "System"

  • Remember to take your graded assignments from the folder.

  Steps

  1. Pick one of the user stories that you already have an estimate for. Create tasks for this user story only. I will provide smaller cards to write the tasks on.
  2. Use the estimation process to create an estimate for each task.
  3. Total the estimates for the tasks and compare them to the estimate for the user story.

  Each team member will turn in to Brightspace a separate document that includes each round of planning poker:

  • Title of the user story or task
  • The spread of estimates, indicating which one is yours
  • The team consensus (if the team was able to reach one in this round)
  • If the consensus changes the overall estimate of the user story
  • Any assumptions that you made
  • Any questions or confusions on the user story or task that is of interest

  I recommend you take notes as you go along. If on paper, do this exercise on a new sheet of paper. The uploaded document can be a PDF or a JPG.

• Week 4 Class 7 Tue Jan 31 Posted: Jan 31

  Announcements

  • Project 1: Requirements Report

  Class

  • HFSD Chapter 3 (continued)

  • Exercise 12: HFSD Chapter 3 Crossword

  • Exercise 13: Team User Story Estimates II

  • Exercise 14: Requirements Report Repository

    Using the instructions in Project 1: Requirements Report, create your repository for the Requirements Report in GitHub Classroom.

  Unless otherwise indicated, exercises are due by 4:30 pm on Wed Feb 01

• Exercise: Team User Story Estimates II Posted: Jan 31

  Continue to determine estimates for your user stories following the procedure from the last Team Meeting. Keep in mind the following:

  • Look carefully at the spread as shown in the book, as it is not just a list of numbers, but a number line
  • Estimates include everything needed for the user story to be implemented and used by or demonstrated in front of/with the customer. This includes coding, testing, documentation, installation, back-end code, UI, everything. A single-user story may not be enough for the customer to release the product, but it must be ready as soon as other user stories are implemented.
  • Never say ".. all we have to do is ". Think carefully about what it would take.
  • Do not assume that your customer will pick the user stories in a particular order (iteration plan order) or want to implement all of them. Each user story must be estimated as a standalone feature.
  • Do not assume another user story is complete before you do the one in front of you. Dependencies exist, but they should not be to simplify the development of user stories.
  • Do not assume that the implementation of a user story is just a slight modification (code-wise) of another user story. Testing, documentation, etc., take just as long in the latter as in the former feature.
  • Actions such as "Modify" or "Delete" do not depend on actions such as "Create" or "Add". Often data is prefilled before the user sees it. I.e., you don't have to have "Add" implemented before you "Delete".

  If you cannot reach a consensus, discuss and perform another round of planning poker. When the team gets a consensus for the estimate, place the estimate at the bottom of the description on a separate line, e.g., "Estimate: 1 day" or "Estimate: 3 days".

  As before, each team member will turn in to Brightspace a separate, new document that includes each round of planning poker:

  • Title of the user story
  • The spread of estimates, indicating which one is yours
  • The team consensus (if the team was able to reach one in this round)
  • Any assumptions that you made
  • Any questions on or confusion with the user story that is of interest

  I recommend you take notes as you go along.

  The document can be a PDF or a JPG.

  Once consensus has been reached, write down the estimate on the user story.

• Project 1: Requirements Report Posted: Jan 31

  Project 1 is due 11:59:59 pm Friday, Feb 10, Monday, Feb 13, 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:

  • User Stories with title, description, estimate, and space for priority
  • Details of the process and procedure that created the User Stories and their Estimates, including the spread and any assumptions
  • General observations on how the team interaction worked, what did and did not work well, and the overall process

  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 report, 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

  • Written in the plain-text formatting syntax Markdown
  • Identify yourself completely at the top of the page. That includes 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 the 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, report format, and your 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.

• Week 3 Class 6 Thu Jan 26 Posted: Jan 26

  Class

  • HFSD Chapter 3 (continued)

  • Exercise 9: HFSD Chapter 3: Iteration Plan p81

  • Exercise 10: HFSD Chapter 3: Who Does What? p86

  • Exercise 11: Team User Story Estimates

  • Exercise 12: HFSD Chapter 3 Crossword Due after next class

• Exercise: Team User Story Estimates Posted: Jan 26

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

  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 a separate report that includes each round of planning poker:

  • Title of the user story
  • The spread of estimates, indicating which one is yours
  • The team consensus (if the team was able to reach one in this round)
  • Any assumptions that you made
  • Any questions on or confusions with the user story that is of interest

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

  If the report is done on a computing device, it is due by the end of class. If the report is written on paper, you have until the regular exercise due date to submit a photo of your report to Brightspace.

  I recommend you take notes as you go along.

  The document can be a PDF or a JPG.

  Once consensus has been reached, write down the estimate on the user story.

• Week 3 Class 5 Tue Jan 24 Posted: Jan 24

  Class

  • HFSD Chapter 2 (continued)

  • Exercise 7: HFSD Chapter 2 Crossword

  • Exercise 8: Team User Stories II

  All exercises due by 4:30 pm on Wednesday, Jan 25.

• Exercise 8: Team User Stories II Posted: Jan 24

  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.

  For this exercise, every invalid user story title will result in a deduction from the overall score. E.g., For 2 invalid user stories titles, I will deduct 2 points.

  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.
• User Story Titles Posted: Jan 24

  Overall feedback based on Exercise 7: Team User Stories.

  User Stories are Actions

  Of the 48 candidate User Stories generated in Team Exercise User Stories, 35 (73%) have invalid User Story titles.

  The following are some that are not valid user story titles

  • Photo Album
  • Notifications of Absence
  • Categories
  • Payment Methods
  • Critic Finder
  • Keyword Tracker
  • Community Hub
  • Pay Feature
  • Notes
  • Trail Share
  • Realtime Map Changes

  User story titles are not things, i.e., they are not nouns. The title is an action to perform followed by what to perform it on. They are in the Verb Object or Verb Phrase form. User story titles are never a single word as they need a verb and an object.

  The title of a user story completes the sentence "The user will be able to …"

  For words that can be both a noun and a verb, e.g., "Report", assume it is a noun, except in cases that include another noun, e.g., "Report a missing item".

  User stories are not tasks for the developer. A single user story often requires multiple tasks.

  Capitalization Style

  In terms of style, choose one of the following:

  • Capitalize all: "Pay With A Credit Card"
  • Capitalize first word: "Pay with a credit card"

  All user stories for each team must follow the same style. I suggest the Capitalize All form, as the book uses this form.

  Misc

  The following are User Story titles that are actions but have other issues:

  • Calculate Station Distance from User Nobody wants to calculate something. They want to view the result. Or to change the outcome.
  • Generate Estimate Nobody wants to generate something. They want to view the results. Or change the outcome.
  • Create Graphs/Charts Too open ended. Which specific graphs?
  • Create/Modify Categories Avoid multiple verbs. Separate into multiple user stories. The ability to modify can be more challenging to implement than the ability to create.
  • Posting recipes Use the imperative form of the verb, e.g., use "Post" instead of "Posting".
  • Messaging Other Users This does have a verb "Messaging". However, once converted into imperative form, i.e., "Message", it is both a noun and a verb. At this point, a verb is needed for clarity, e.g., "Send Message To Other Users".
  • The description of user stories is not an example from the past or the future. It is a description of what the user will be able to do.

• Week 2 Class 4 Thu Jan 19 Posted: Jan 19

  Class

  • HFSD Chapter 2
  • Exercise 6: Team User Stories
• Exercise 6: Team User Stories Posted: Jan 19

  

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

• Week 2 Class 3 Tue Jan 17 Posted: Jan 17

  Announcements

  • Exercise 3: App Idea Still grading

  Class

  • HFSD Chapter 1
  • Exercise 5: HFSD Chapter 1 Crossword

  Unless noted otherwise, all exercises are due by 4:30 pm on Wed Jan 18

• Week 1 Class 2 Thu Jan 12 Posted: Jan 12

  Announcements:

  • Scores I posted the scores for the Exercises 1 & 2
  • Syllabus In the syllabus, "3460" is replaced by "CPSC"
  • Office Hours
  • Notes The class notes have a bunch of default and custom hot keys. Type a "?" to see a list.
  • Notes The U.S. News 100 Best Jobs was updated to 2023 soon after I updated the notes for the semester. "Software Developer" is back to #1!
  • Class Survey Results

  Class

  • Notes: Context
  • Notes: Roots
  • Exercise 3: Teams Due: 4:30 pm on Fri Jan 13

  • Exercise 4: App Idea - Upload to Brightspace. Due by 4:30 pm on Mon, Jan 16

    All applications start with an idea or a need. In the role of a user, write a one-page paper (at least 350 words) that is a description of an application. The paper includes who would use it and its features. The application can be one that you create yourself or an existing program.

    Guidelines:

    • Include a name for the app at the top of the paper.
    • Do not identify yourself in the paper.
    • 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.
    • If the application already exists, be creative with your name and description.
    • If you have a great app idea, this is not the place to write it down. Your writeup may be shared with others in the class, or discussed (anonymously) in front of the entire class.
• Exercise: Teams Posted: Jan 12

  You will form a team in class of 3 or 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. The choices are one of the Three Stooges (Moe, Larry, Curly, Shemp, Curly Joe), one of the Marx Brothers (Chico, Harpo, Groucho, Gummo, Zeppo), or one from Star Wars. Pick at least 4 names.

  Email Dr. Collard the following:

  • Use the following email link to get the right subject: CPSC480-010 Team
  • Make sure to CC all members of the team using their UA email address
  • The first part of the message is a list of the team members. The second part of the message is a prioritized list of 4 team names (most wanted to least wanted)
  • The list of the team members in CSV (Comma-Separated Values) format and includes (in this order)
    1. Lastname
    2. Firstname
    3. UA email
  • The email is to have no other content

  Example content of the email (but don't indent):

  Doe,John,johndoe@uakron.edu
  Doe,Jane,janedoe@uakron.edu
  Doe,Brian,briandoe@uakron.edu
  Doe,Suzy,suzydoe@uakron.edu
  
  Harpo
  Moe
  Yoda
  Zeppo
  

  The purpose of a team is not just to divide the work, but also to raise the overall quality. More than one person should 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 and CC list. Exercises are not accepted and do not receive points if they do not have the proper form and content.

• Week 1 Class 1 Tue Jan 10 Posted: Jan 10

  Announcements

  • Syllabus
  • GitHub We use GitHub and GitHub Classroom in the class to manage source code for projects, exercises, 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. You will need your GitHub account for Thursday's class.

  • 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 content, 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 into Brightspace.

  • Notes: Context

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

  All exercises are due by 4:30 pm on Wed Jan 11

• Welcome Posted: Jan 09

  Greetings and welcome to CPSC 480 Software Engineering (SE) for Spring 2023.

  • Syllabus The syllabus for the course is on the main course page. It is a draft, but I will finalize it 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 There are two textbooks for the course. We start with the Head First Software Development (HFSD), available from Safari Books Online, from a link at the bottom of the main course page.
  • GitHub We use GitHub and GitHub Classroom in the class 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, Jan 10 at 3:30 - 4:45 pm in Arts & Sciences (CAS) room 134