<ul>
<li>User Stories and Use Cases
<ul>
<li>Please see Quiz 1, Quiz 2, Half-Exam 1, or Half-Exam 2.
</ul>
<li>Testing, Verification, and Validation
<ul>
<li>Please see Quiz 1, Quiz 2, Half-Exam 1, or Half-Exam 2.
</ul>
<li>Designing UML class diagrams
<ul>
<li>Please see Quiz 1, Quiz 2, Half-Exam 1, or Half-Exam 2.
</ul>
<li>Writing Unit Tests
<ul>
<li>Describe the differences in who writes and performs unit tests and acceptance tests
<li>Describe the differences in size of the software components tested with unit tests and acceptance tests
<li>Describe the difference between the assertEquals and assertSame tests
<li><b>Provide an example of when the assertThrows test would be useful</b>
<li>User Acceptance Tests
<li>List the key elements of a user acceptance test
<li>Explain the importance of a user being involved in writing use cases and acceptance tests
<li>Write acceptance criteria including specific values for input provided by the user and output expected from the program
</ul>
<li>Version Control
<ul>
<li>Describe the advantages of using a version control system (VCS) when developing code in a team environment
<li><b>Describe the advantages of a VCS system over a shared hard-drive / usb drive / network drive or Google Docs, Office 365, etc.</b>
<li><b>Describe the lock-modify-unlock procedure</b>
<li>Describe the copy-modify-merge procedure
<li><b>Describe the situations in which the lock-modify-unlock procedure may still be useful</b>
<li>Describe why modern VC systems prefer the copy-modify-merge procedure
<li>Describe where repositories are stored in centralized and distributed control systems
</ul>
<li>Git
<ul>
<li>Use the basic Git commands (status, add, commit, and push) to check in a change you made to the code and share it with your peers
<li><b>Explain how distributed version control impacts the standard git workflow.</b>
<li><b>Describe the purpose of the stage in making a commit</b>
<li><b>Describe the purpose of a commit — a repository history entry</b>
<li>Explain why performing the pull command frequently makes development easier in the long run
<li>Describe what causes merge conflicts to occur
<li><b>Use a text editor and the basic Git commands to resolve a merge conflict</b>
<li><b>Review your work with the git status and git diff commands before staging and committing your code</b>
<li><b>Use the <a href="https://faculty-web.msoe.edu/yoder/se2030/Git#xkcd">xkcd approach</a> to resolving a Git mess. (The Git equivalent of turn it off and turn it back on :-))</b>
</ul>
<li>Advanced Git Topics (branching, merge requests, Git Flow)
<ul>
<li>Explain the motivation for keeping the master branch separate from the dev branch
<li>Describe the advantages and disadvantages of creating a feature branch
<li>Describe how a Git tag can be used within Git Flow
<li>Describe the advantages and disadvantages of a hotfix or a release branch. (These are also illustrated within Git Flow)
</ul>
<li>Sequence diagrams
<ul>
<li>Draw a sequence diagram including objects, lifelines, messages, return values, and method boxes
<li>Tell a single story with a sequence diagram by avoiding if-else blocks and loops and including return values to show information flow
<li>Include data structures in a sequence diagram as objects to illustrate implementation details within the sequence diagram narrative
</ul>
<li>Defect Tracking
<ul>
<li>Explain why the term "defect" leads to better root-cause analysis than the term "bug"
<li>Explain the advantage of detecting defects early in the development process
<li>Explain how a defect would flow between the New, Valid, Disputed, WIP, Fixed, and Closed states.
<li>Explain why, when tracking the rate that defects are fixed, we look at the rate of defects going from Fixed to Closed rather than from WIP to Fixed.
<li>Describe how the known to unknown defect ratio may be estimated in practice
<li>Describe how the known to unknown defect ratio may change as QA (testers) and coders are added to a project.
<li>Define "Technical Debt"
<li>Expound upon the similarities between technical and financial debt and the impact this has on project planning
<li>(optional) Describe how technical debt can be addressed while continuing to develop other forms of value for the customer and the company
<li>Give examples of avoidable and unavoidable technical debt
<li>Give examples of strategic and irresponsible technical debt
</ul>
</ul>