CSC-210 cheat sheet

Waterfall executes phases sequentially (requirements, design, implementation, verification, maintenance) with each phase baselined before the next begins; rework cost rises sharply the later a defect is found.

Incremental delivery ships functional subsets of the final product in successive increments; iterative development instead reworks a full-product design through repeated cycles, so iterative builds may be throwaway while increments are not.

The V-model pairs each construction phase with a matching test level: requirements↔acceptance, design↔system/integration, detailed design↔unit testing.

Scrum roles are Product Owner, Scrum Master, and Developers; artifacts are Product Backlog, Sprint Backlog, and Increment; the Sprint is timeboxed to 1 month or less with a fixed-length Daily Scrum of 15 minutes.

Kanban limits work in progress per column and measures cycle time and throughput; it prescribes no fixed iterations, unlike Scrum's timeboxed Sprints.

Extreme Programming practices include pair programming, test-first development, continuous integration, small releases, and collective code ownership.

Rational Unified Process is organized into four phases (Inception, Elaboration, Construction, Transition) crossed with disciplines; the Architecture Centric, Use-Case Driven, Iterative and Incremental triad is its defining principle.

Prototyping is chosen when requirements are unstable or poorly understood; the throwaway prototype must be discarded so that quality attributes are not inherited by the delivered system.

DevOps merges development and operations into one value stream, emphasizing automation of build, test, and deployment plus shared ownership of production reliability.

Elicitation techniques: interviews, workshops/focus groups, observation (job shadowing), document analysis, questionnaires, and prototyping; each targets tacit versus documented knowledge differently.

A functional requirement states a behavior or service; a non-functional requirement constrains how well it is done (performance, security, availability, usability) and is often testable only via measurable thresholds.

Requirements classification uses MoSCoW (Must, Should, Could, Won't) for prioritization and the Volere-style distinction between functional, non-functional, and constraints.

A use case describes actor-goal interaction with main success scenario plus alternative and exception flows; it is not a design document and should avoid UI detail.

INVEST criteria for user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Traceability links requirements forward to design, code, and tests and backward to their source; a requirements traceability matrix exposes orphans and gaps.

Requirements validation checks completeness, consistency, feasibility, and verifiability; ambiguity is detected via reviews, not by testing, because untestable requirements cannot be verified.

A requirement is verifiable only if a finite, cost-effective process exists to check whether the delivered system meets it; words like 'fast' or 'user-friendly' fail unless quantified.

SOLID: Single Responsibility (one reason to change), Open/Closed (open for extension, closed for modification), Liskov Substitution (subtypes usable wherever the base type is), Interface Segregation (no client forced to depend on unused methods), Dependency Inversion (depend on abstractions, not concretions).

Coupling measures interdependence between modules; cohesion measures how strongly related the responsibilities inside one module are. Good design targets low coupling and high cohesion.

Law of Demeter: a method should call only methods of its own object, its parameters, objects it creates, and its direct components - not methods of objects returned by other calls (avoid train wrecks).

GRASP patterns: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Architectural styles: layered (strict vs relaxed layers), client-server, pipe-and-filter, event-driven/publish-subscribe, microservices, service-oriented, and microkernel (plug-in).

Microservices trade operational complexity and distributed-systems failure modes for independent deployability and per-service scaling; a monolith trades those for simpler transactions and deployment.

MVC separates model (state and rules), view (presentation), and controller (input handling); the pattern reduces coupling between UI and domain logic but adds indirection.

Design patterns are catalogued by intent: creational (Factory Method, Builder, Singleton), structural (Adapter, Decorator, Facade, Proxy), behavioral (Observer, Strategy, Template Method, Command).

Separation of concerns and information hiding (Parnas) hold that modules should hide design decisions likely to change, exposing only stable interfaces.

Array indexing is O(1); insertion or deletion in the middle is O(n) because elements shift. A dynamic array amortizes append to O(1) but a single resize is O(n).

Linked list: O(1) insert/delete given a reference to the node, O(n) search; singly linked lists cannot traverse backward; a doubly linked list costs extra memory per node.

Stack is LIFO (push/pop), queue is FIFO (enqueue/dequeue); a deque allows both ends; a priority queue orders by key and is typically a binary heap with O(log n) insert and extract-min.

Hash table average case O(1) lookup; worst case O(n) with collisions. Load factor = entries / buckets; open addressing versus separate chaining are the two main collision strategies.

Balanced search trees (AVL, red-black) give O(log n) search, insert, delete; an unbalanced BST degrades to O(n) on sorted input.

Binary heap: parent at floor((i-1)/2), children at 2i+1 and 2i+2; build-heap is O(n), heapsort is O(n log n) and in-place but not stable.

Sorting: quicksort average O(n log n), worst O(n²), in-place, not stable; mergesort O(n log n) always, stable, O(n) extra space; insertion sort O(n²) but O(n) on nearly sorted input.

Graph traversal: BFS uses a queue and finds shortest paths in unweighted graphs; DFS uses a stack or recursion and is the basis for topological sort and cycle detection. Dijkstra requires non-negative edge weights.

Big-O describes an upper bound on growth; O(1) < O(log n) < O(n) < O(n log n) < O(n²) < O(2ⁿ) < O(n!). Recursion depth consumes stack space, so a recursive traversal is O(h) space.

Verification asks 'are we building the product right' (conformance to specification); validation asks 'are we building the right product' (meets user needs).

Test levels: unit (isolated component), integration (interfaces between components), system (end-to-end against requirements), acceptance (user/customer validation).

Black-box techniques: equivalence partitioning, boundary value analysis (defects cluster at boundaries), decision tables, state transition testing, pairwise/combinatorial testing.

White-box coverage strength, weakest to strongest: statement < branch/decision < condition < decision-condition (MC/DC) < multiple-condition < path. 100% statement coverage does not imply 100% branch coverage.

Cyclomatic complexity V(G) = E − N + 2 (edges − nodes + 2) or P + 1 (predicates + 1); it equals the number of independent paths and the minimum number of branch tests for full branch coverage.

Regression testing re-runs existing tests after change; a smoke test is a shallow build-acceptance check; a sanity test is a narrow check of one fix.

Test pyramid: many fast unit tests, fewer service/integration tests, few slow UI tests; the ice-cream-cone anti-pattern inverts this.

Defect cost grows with the phase in which it is found; a defect escaping to production costs far more than one caught in review or unit test.

Static analysis and code review find defects without executing code (verification); dynamic testing executes the system. Both are quality assurance activities, while QA as a whole is process-oriented.

Configuration items are the versioned artifacts (source, build scripts, tests, docs, infrastructure definitions); a baseline is a reviewed, fixed configuration that can only change through a change control process.

Version control branching strategies: trunk-based (short-lived branches, frequent merges), Git Flow (long-lived develop and release branches), and feature branching; trunk-based reduces merge conflicts and enables continuous integration.

CI requires every commit to trigger an automated build and test run on a shared mainline; CD (continuous delivery) keeps the mainline always deployable, while continuous deployment automatically releases every passing change.

A build pipeline stage gates on quality: compile → unit test → static analysis → integration test → artifact publish → deploy to staging → deploy to production.

Infrastructure as Code declares environments in versioned files (Terraform, Ansible, CloudFormation); idempotency means applying the same definition repeatedly yields the same state.

Blue-green deployment keeps two identical environments and switches traffic at once for fast rollback; canary release shifts a small traffic percentage first to limit blast radius.

Semantic versioning: MAJOR.MINOR.PATCH - MAJOR for incompatible changes, MINOR for backward-compatible features, PATCH for backward-compatible fixes.

Immutable artifacts and container images guarantee that what was tested is what is deployed; rebuilding at deploy time breaks that guarantee.

Change management records a request, impact analysis, approval, implementation, and verification; emergency changes still require retrospective documentation.

COCOMO II effort in person-months is a function of size raised to an exponent scaled by cost drivers; the exponent exceeds 1.0 for large, complex projects, so effort grows superlinearly with size.

Function points measure size from user-visible functionality (external inputs, outputs, inquiries, internal logical files, external interface files), independent of implementation language.

Brooks's Law: adding people to a late software project makes it later, because of ramp-up cost and communication overhead that grows roughly as n(n−1)/2 links.

Critical path is the longest duration path through the dependency network; it determines minimum project duration, and its slack is zero.

PERT three-point estimate = (Optimistic + 4×Most Likely + Pessimistic) / 6; the standard deviation = (Pessimistic − Optimistic) / 6.

Earned Value: CV = EV − AC; SV = EV − PV; CPI = EV / AC; SPI = EV / PV. CPI below 1.0 means over budget; SPI below 1.0 means behind schedule.

Risk exposure = probability × impact; risk response types are avoid, mitigate, transfer, accept, and exploit (for opportunities).

Planning poker uses relative story points and consensus estimation; velocity is completed points per iteration and is used to forecast, not to compare teams.

Parkinson's Law: work expands to fill the time available; timeboxing exploits it. The cone of uncertainty narrows as a project progresses, so early estimates carry the widest range.

OWASP Top 10 categories include broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, identification/authentication failures, and SSRF.

Injection (SQL, command, LDAP) is prevented by parameterized queries and input validation at trust boundaries; output encoding prevents cross-site scripting, not input filtering alone.

Defense in depth layers controls; least privilege grants only the access needed to perform a task; fail-safe defaults deny by default.

Threat modeling (STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) identifies threats during design, when fixes are cheapest.

Symmetric encryption (AES) uses one shared key and is fast; asymmetric encryption (RSA, ECC) uses a public/private pair for key exchange and signatures. Hashing (SHA-256) is one-way; passwords need a salted, slow KDF such as bcrypt, scrypt, or Argon2.

Authentication verifies identity; authorization decides permissions. Multi-factor authentication combines knowledge, possession, and inherence factors.

Secure SDLC shifts security left: security requirements, threat modeling in design, static/dynamic analysis in build, penetration testing before release, and monitoring after.

ACM/IEEE Software Engineering Code of Ethics principles: Public, Client and Employer, Product, Judgment, Management, Profession, Colleagues, Self. The Public interest takes precedence over all others.

Confidentiality, Integrity, and Availability (CIA triad) frame security requirements; non-repudiation and accountability are supported by audit logging.