CS100 Software Engineering Lecture and Discussion Notes

Vocabulary flashcards covering software development methodologies, Git version control, prerequisites and architecture, testing techniques, continuous integration/deployment, and UML diagrams.

Waterfall Method

A linear software development model where progress flows sequentially through phases without returning to previous stages; typically used for control systems and highly regulated industries where systems are deployed once and rarely updated.

Kanban

An Agile framework developed at Toyota that visualizes tasks on a board using cards and columns representing pipeline stages, emphasizing Work In Progress (WIP) limits so available team members pull and address work items directly.

Scrum Pillars

The three foundational principles of the Scrum framework: transparency, inspection, and adaptation.

Scrum Values

The five core values governing a Scrum team: commitment, courage, focus, openness, and respect.

Scrum Roles

The defined roles within a Scrum team designed to keep members focused: the Scrum Master (enforces Scrum principles and tracks progress), the Product Owner (acts as the voice of the user and manages requirements), and the Scrum Team (developers).

Centralized vs. Distributed Version Control Systems

Two architectures for tracking changes: Centralized VCS utilizes a single central server repository that client working copies commit to and update from, whereas Distributed VCS (DVCS) provides each workstation with its own local repository, using push and pull operations to sync with a remote server repository.

git clone

A Git command that copies an entire object graph from a remote repository into a local directory and automatically checks out the main branch.

git fetch vs. git pull

git fetch downloads commits and changes from a remote repository to the local repository without altering the working directory, whereas git pull fetches the changes and immediately merges them into the current working workspace.

git revert

An undo operation that inverts the changes introduced by a specific commit and creates a new commit containing the inverted state, leaving the original project history intact.

The 3 C's of User Stories

The three components of user stories: Card (stories written on note cards with estimates and notes), Conversation (details clarified through discussions with the Product Owner), and Confirmation (acceptance tests that verify the story is correctly coded).

Epic

A large user story that represents a significant body of work, which is subsequently broken down into smaller, specific user stories.

Theme

A high-level collection or grouping of related user stories.

Semantic Versioning

A software versioning scheme structured as Major.minor.patch (e.g., v4.2.1), indicating the scale and impact of changes in a release.

Problem Definition

A clear one- or two-page description of what problem needs solving with zero reference to technical solutions, written entirely in user language to serve as a project foundation.

Software Architecture

The top-level technical design of a software system that guides programmers and partitions tasks so multiple teams can work independently, preventing expensive modifications during and after construction.

Test-Driven Development (TDD)

A software development approach where developers write automated tests before writing production code, following a cycle of writing a failing test, writing the minimum code required to make it pass, and refactoring to eliminate redundancy.

Arrange-Act-Assert (AAA)

The standard three-stage pattern of a unit test: Arrange (set up and initialize the component being tested), Act (execute the behavior or apply stimulus), and Assert (verify that the resulting behavior matches expectations).

ASSERT vs. EXPECT (Google Test)

Verification macros in Googletest: ASSERT generates fatal failures that abort execution of the current test function immediately, whereas EXPECT generates non-fatal failures that permit the test to continue executing until completion.

F.I.R.S.T. Principles

Criteria for clean unit testing: Fast (run quickly), Independent (isolated from other tests and modules), Repeatable (environment-agnostic), Self-validating (boolean pass/fail without reading logs), and Timely (written just before production code).

Google Test Starter Main Function

The standard C++ entry point implementation for running a Googletest suite, which initializes the framework via ::testing::InitGoogleTest(&ac, av); and returns RUN_ALL_TESTS(); to run all registered tests.

Smoke Testing

Preliminary high-level testing designed to confirm that critical core features function well enough to justify full, detailed testing; builds that fail smoke tests are rejected immediately.

Alpha / Beta Testing

Formal testing conducted by a subset of real customers prior to widespread release to ensure system functionality meets business requirements from an end-user perspective.

User Acceptance Testing (UAT)

The final validation phase performed by the client to verify that end-to-end system flows satisfy business requirements and user needs before the product goes live.

Stress Testing

A form of non-functional testing that pushes a software system past its specified operational limits (such as extreme data input, queries, or storage volume) to identify how and when it fails.

Regression Testing

The practice of re-executing functional and non-functional tests on existing features to verify that recent code changes, bug fixes, or enhancements have not introduced new defects.

Code Coverage Formula

The mathematical metric expressing test coverage: \text{Code coverage} = \t\left(\frac{\text{lines of code executed by tests}}{\text{Total number of lines in a system component}}\right) \times 100

Code Coverage Benchmarks

Standard industry thresholds: $100\%$ coverage is ideal for newly committed code, $90\%$ is the benchmark for regression testing, $80\%$ is the minimum acceptable threshold, and $60\%-70\%$ is typical for unmonitored codebases.

Continuous Integration (CI)

A software engineering practice where developers frequently merge code changes into the main repository branch, automatically validating each integration with builds and tests to prevent integration conflicts.

Continuous Delivery vs. Continuous Deployment

Continuous Delivery automates testing and release staging so code can be deployed to production reliably at the click of a button; Continuous Deployment extends this by automatically deploying all passed builds directly into production without human intervention.

Valgrind Memcheck Clean Criteria

The required indicators of a memory-leak-free C++ program in Valgrind: zero errors, the total number of heap frees equal to allocs, and a leak summary showing $0$ bytes in $0$ blocks across all categories.

UML Class Diagram Compartments

The three standard divisions of a UML class box: the top compartment contains the class name, the middle compartment lists class attributes (variables), and the bottom compartment specifies class operations (functions).

UML Class Relationship Connectors

The graphical notations defining class interactions: open solid arrow for Association, closed hollow triangular arrowhead on a solid line for Inheritance, closed hollow triangle on a dashed line for Realization/Implementation, open dashed arrow for Dependency, hollow diamond for Aggregation, and solid filled diamond for Composition.

Top-Down vs. Bottom-Up Design

Architectural strategies: Top-down designs high-level modules first using stubs (easier to prototype, harder to unit test), while bottom-up builds low-level utility modules first (easier to unit test, harder to prototype).