EXMP cheat sheet

A system is a set of interacting components with a boundary, inputs, outputs, and a purpose; the boundary determines what is in scope for analysis.

Emergent behavior arises from component interactions and cannot be predicted from inspecting components in isolation.

Feedback loops are either reinforcing (amplifying change) or balancing (resisting change); loop polarity is the product of the signs of its links.

A model is a simplified representation; all models are wrong to some degree, and validity means fit for a stated purpose, not universal truth.

The abstraction ladder trades detail for generality: higher abstraction increases reuse but reduces fidelity to any single instance.

Coupling measures interdependence between modules; cohesion measures relatedness within a module. Low coupling with high cohesion is the standard target.

Requirements traceability links each requirement forward to design and tests and backward to its source, enabling impact analysis for change.

Cost of change grows with lifecycle stage; defects found in operations typically cost orders of magnitude more to fix than those found in requirements.

Functional requirements state what the system does; non-functional requirements constrain how well it does it (performance, availability, usability, security).

A SMART requirement is specific, measurable, achievable, relevant, and time-bound; unmeasurable adjectives such as 'fast' or 'user-friendly' are defects.

MoSCoW prioritization classifies items as Must, Should, Could, or Won't; Must items must all fit within the fixed timebox or scope is renegotiated.

Elicitation techniques include interviews, workshops, observation, document analysis, surveys, and prototyping; each has different bias profiles.

A use case describes actor-goal interaction with main success scenario plus alternate and exception flows; it is not a design specification.

Estimation by analogy uses historical similar work; three-point estimation computes expected value as (optimistic + 4×likely + pessimistic) / 6.

A work breakdown structure decomposes deliverables hierarchically; the lowest level is a work package that can be estimated and assigned.

Scope creep is uncontrolled addition of requirements without corresponding adjustment to time, cost, or resources; change control is the countermeasure.

Layered architecture organizes components into strata where each layer depends only on the layer below, isolating change and enabling substitution.

Separation of concerns assigns each module one reason to change; the single responsibility principle is its expression at class level.

An interface contract specifies inputs, outputs, preconditions, postconditions, and error behavior, decoupling callers from implementations.

Design patterns are named reusable solutions to recurring problems; they document tradeoffs, not code, and misapplying them adds accidental complexity.

Architecture quality attributes are assessed through scenarios: stimulus, source, environment, artifact, response, and response measure.

The CAP theorem states that a distributed data store cannot simultaneously guarantee consistency, availability, and partition tolerance under a network partition.

Idempotency means repeating an operation yields the same result as performing it once; it is required for safe retries in distributed systems.

A design review compares the design against requirements and quality scenarios; reviewers should include those who did not author the design.

Version control branching strategies (trunk-based, feature branch, release branch) trade integration frequency against isolation of in-progress work.

Configuration items are placed under change control with a unique identifier, version, and baseline; a baseline is a fixed reference point for comparison.

Continuous integration requires a single source repository, automated build, automated tests, and a fast feedback loop on every commit.

Infrastructure as code stores environment definitions in version control, making environments reproducible and auditable rather than hand-configured.

Build reproducibility requires pinned dependency versions, deterministic build steps, and recorded toolchain versions.

Environment parity means development, test, and production match in configuration and dependency versions; drift is a leading cause of deployment failure.

Secrets must not be committed to source control; they belong in a secrets manager injected at runtime, with rotation and least-privilege access.

A rolling deployment replaces instances incrementally; blue-green swaps whole environments; canary routes a small traffic fraction to the new version first.

Verification asks whether the product was built right against specification; validation asks whether the right product was built against user need.

The test pyramid favors many fast unit tests, fewer service-level integration tests, and few slow end-to-end UI tests.

A test case has preconditions, inputs, steps, and expected results; a test without an expected result is not executable as a pass/fail check.

Equivalence partitioning divides inputs into classes treated alike; boundary value analysis tests the edges of each class, where defects cluster.

Decision tables capture combinations of conditions and resulting actions; they expose gaps that prose rules often hide.

Code coverage measures executed lines or branches, not correctness; high coverage with weak assertions still permits defects.

Regression testing confirms that change has not broken existing behavior; the suite should be selected by risk and impact, not run blindly.

Defect severity reflects impact on the system; priority reflects urgency of fix. The two are independent and can diverge.

The four service metrics are latency, traffic, errors, and saturation; saturation is the resource closest to capacity, not necessarily CPU.

An SLA is a contractual commitment; an SLO is an internal target; an SLI is the measured indicator. Error budget is 1 minus the SLO.

Mean time to recovery (MTTR) is reduced by observability, runbooks, and automated rollback more effectively than by prevention alone.

The three pillars of observability are logs, metrics, and traces; correlation identifiers tie them together across service boundaries.

Symptom-based alerting pages on user-visible impact; cause-based alerting pages on internal conditions and produces alert fatigue.

Corrective maintenance fixes defects; adaptive maintenance responds to environment change; perfective maintenance improves performance or maintainability; preventive maintenance reduces future failure.

A post-incident review is blameless and produces action items with owners and dates; the goal is systemic learning, not individual attribution.

Change management requires rollback plans, verification steps, and a communication path before a production change is approved.

The CIA triad comprises confidentiality, integrity, and availability; each control should be mapped to the property it protects.

Authentication proves identity; authorization determines permitted actions; auditing records what occurred. Confusing the first two is a common design flaw.

Defense in depth layers independent controls so that failure of one does not grant access; single controls are assumed to fail.

Least privilege grants the minimum rights needed for a task and for the minimum duration; standing admin access violates it.

Risk is characterized as likelihood times impact; treatment options are avoid, mitigate, transfer, and accept, each requiring documented rationale.

Encryption protects data at rest and in transit but not data in use; key management is the limiting factor in real deployments.

Input validation and output encoding defend against injection; parameterized queries and context-aware escaping are the specific mechanisms.

Compliance frameworks define controls and evidence requirements; compliance is not equivalent to security, since it is a point-in-time assessment against a baseline.