CPN CPE Software Engineering cheat sheet

Functional requirements state what the system shall do; non-functional requirements constrain how (performance, security, usability, availability) and are testable only with measurable thresholds.

A requirement is verifiable if a finite, objective test can decide pass/fail; 'user-friendly' fails, '95% of tasks completed in under 30 s by trained users' passes.

IEEE 830 / ISO-IEC-IEEE 29148 structure: purpose, scope, definitions, stakeholders, constraints, functional requirements, quality attributes, interfaces, acceptance criteria.

Traceability matrix maps each requirement to design element, code unit, and test case; bidirectional links surface orphans (design with no requirement) and gaps (requirement with no test).

Elicitation techniques: interviews, workshops, observation, document analysis, prototyping, questionnaires; each yields different fidelity and cost trade-offs.

MoSCoW prioritization: Must have, Should have, Could have, Won't have this time; 'Must' items define the minimum usable release.

User story format: As a , I want , so that ; acceptance criteria expressed as Given/When/Then scenarios.

Requirements volatility is measured as the fraction of requirements changed after baseline; high volatility signals unstable scope and predicts rework cost.

Coupling types ranked weakest to strongest: data, stamp, control, external, common, content; aim for data coupling and avoid content coupling.

Cohesion ranked strongest to weakest: functional, sequential, communicational, procedural, temporal, logical, coincidental; prefer functional cohesion.

SOLID: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.

Architectural styles: layered, pipe-and-filter, client-server, event-driven (implicit invocation), microservices, service-oriented, repository/blackboard, MVC.

Quality attribute scenarios: stimulus, source, environment, artifact, response, response measure; used to evaluate architectures (ATAM).

Design patterns by category: creational (Abstract Factory, Builder, Factory Method, Prototype, Singleton), structural (Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy), behavioral (Observer, Strategy, Command, State, Template Method, Visitor).

Separation of concerns and information hiding (Parnas) localize likely change; modules should hide design decisions most likely to change.

Conway's Law: system structure mirrors the communication structure of the organization that produced it; architecture reviews should consider team topology.

Defensive programming: validate inputs at trust boundaries, fail fast, use assertions for internal invariants and exceptions for recoverable conditions.

Cyclomatic complexity V(G) = E - N + 2P where E = edges, N = nodes, P = connected components; values above ~10 indicate refactoring candidates.

Code review defect detection is typically more cost-effective than testing for finding logic and design defects; reviews should be small (200-400 LOC) and time-boxed.

Immutability and pure functions reduce state-related defects; side effects should be isolated at module boundaries.

Naming and formatting conventions reduce comprehension cost; consistency within a codebase outweighs individual style preference.

Exception handling rules: catch only what you can handle, do not swallow exceptions, preserve stack traces, use finally/try-with-resources for cleanup.

Static analysis tools detect style violations, dead code, null dereferences, and common vulnerability patterns before execution.

Refactoring is behavior-preserving restructuring; it should be covered by automated tests and performed in small, reversible steps.

Verification asks 'did we build the product right'; validation asks 'did we build the right product'.

Test levels: unit, integration, system, acceptance; each has distinct objectives and typical defect classes.

Black-box techniques: equivalence partitioning, boundary value analysis, decision tables, state transition testing, pairwise/combinatorial testing.

White-box coverage criteria weakest to strongest: statement, branch/decision, condition, MC/DC, path; 100% path coverage is generally infeasible.

Equivalence partitioning: divide inputs into classes where all members are expected to behave identically; test one representative per class plus boundaries.

Boundary value analysis targets off-by-one defects at edges of valid ranges: min-1, min, min+1, max-1, max, max+1.

Regression testing re-runs a subset of tests after change; test selection can be risk-based, coverage-based, or change-based.

Defect cost grows roughly an order of magnitude per phase it survives; a requirements defect found in production can cost 100x more than one caught in review.

Static verification (reviews, inspections, analysis) finds defects without executing code; dynamic verification (testing) requires execution.

Maintenance categories (ISO 14764): corrective, adaptive, perfective, preventive; perfective typically consumes the largest share of effort.

Lehman's laws: continuing change, increasing complexity, large-program evolution, organizational stability, conservation of familiarity, continuing growth, declining quality.

Technical debt: deliberate vs. inadvertent, prudent vs. reckless; interest is paid as slower future change, principal is the cost to remediate.

Refactoring vs. reengineering: refactoring preserves external behavior at small scale; reengineering restructures and may alter architecture.

Reverse engineering recovers design information from code; reengineering follows with forward engineering to a new form.

Legacy system modernization options: encapsulate, rehost, replatform, refactor, rearchitect, rebuild, replace; choose by risk and business value.

Impact analysis identifies artifacts affected by a proposed change; combined with dependency graphs it estimates change ripple and regression scope.

Software decay manifests as increasing change cost, rising defect density, and decreasing comprehensibility over successive releases.

Configuration items are any artifacts placed under version control: source, build scripts, requirements, test cases, infrastructure definitions.

Baselines are formally approved snapshots; changes after baseline require change control board approval.

Version control branching strategies: trunk-based, GitFlow, release branches; trunk-based reduces merge cost but requires strong automated testing.

Continuous integration requires automated build and test on every commit; a broken build is fixed before new work is merged.

Quality models: ISO/IEC 25010 defines functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability.

Defect metrics: defect density (defects per KLOC or per function point), defect removal efficiency = defects found before release / total defects.

Audit types: configuration audit (functional and physical configuration audit) verifies that delivered items match documented baselines.

Release management distinguishes build, release candidate, and deployed release; each release must be reproducible from a tagged baseline.

Critical path is the longest duration path through the dependency network; zero float on its activities determines project duration.

Earned value: CV = EV - AC, SV = EV - PV, CPI = EV/AC, SPI = EV/PV; CPI < 1 means over budget.

Estimate at completion EAC = BAC / CPI when current cost performance is expected to persist.

COCOMO II effort = A * Size^E * product of cost drivers; exponent E > 1 reflects diseconomy of scale.

Function points measure functional size from logical transactions and data; used to normalize productivity across technologies.

Brooks's Law: adding people to a late project makes it later, due to communication overhead and ramp-up cost.

Risk management: identify, analyze (probability x impact), plan response (avoid, mitigate, transfer, accept), monitor.

PERT expected duration = (O + 4M + P) / 6; variance = ((P - O)/6)^2; used to estimate schedule uncertainty.

Make-or-buy and ROI analysis compare net present value of build vs. buy vs. reuse alternatives over the system life.

Waterfall: sequential phases with phase-gate reviews; suits stable, well-understood requirements and contractual milestones.

Incremental and iterative models deliver working software in increments; risk is reduced by early feedback.

Spiral model: risk-driven iterations, each with objectives, risk analysis, engineering, and evaluation quadrants.

V-model pairs each development phase with a corresponding verification phase (requirements/acceptance, design/system, detailed design/integration, code/unit).

Scrum events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective; artifacts: Product Backlog, Sprint Backlog, Increment.

Kanban limits work in progress and optimizes flow; lead time and cycle time are the primary metrics.

CMMI maturity levels 1-5: Initial, Managed, Defined, Quantitatively Managed, Optimizing.

DevOps integrates development and operations via CI/CD pipelines, infrastructure as code, and observability.

UML diagram classes: structural (class, component, deployment, package) and behavioral (use case, activity, sequence, state machine).

OWASP Top 10 categories include broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components.

Injection prevention: parameterized queries, input validation, output encoding, least privilege for database accounts.

Threat modeling (STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) identifies threats before code is written.

Authentication vs. authorization: authentication verifies identity; authorization decides permitted actions on resources.

Secure SDLC integrates security activities into each phase: security requirements, threat modeling, secure coding, security testing, incident response.

Static application security testing (SAST) analyzes source; dynamic testing (DAST) probes running applications; software composition analysis (SCA) checks dependencies.

Build tools and CI/CD pipelines: Maven/Gradle, Jenkins/GitHub Actions, container registries; reproducibility requires pinned dependency versions.