CPN CPE Software Engineering flashcards
CPN CPE Software Engineering · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Functional requirement
- A statement of a service or behavior the system shall provide, expressed so that a test can determine whether the delivered system satisfies it.
- Non-functional requirement
- A quality constraint on the system such as performance, security, availability, or usability, stated with a measurable threshold so it can be verified objectively.
- Requirements traceability matrix
- A table linking each requirement to its design elements, code, and test cases, revealing requirements without tests and design elements without requirements.
- MoSCoW prioritization
- A ranking scheme dividing requirements into Must have, Should have, Could have, and Won't have this time, where Must items define the minimum acceptable release.
- Acceptance criteria
- Conditions a product increment must satisfy to be accepted by the stakeholder, often written as Given/When/Then scenarios attached to a user story.
- Coupling
- The degree of interdependence between modules, ranked from data coupling (weakest, preferred) through stamp, control, external, and common to content coupling (strongest, avoided).
- Cohesion
- The degree to which elements inside a module belong together, ranked from functional cohesion (strongest) down through sequential, communicational, procedural, temporal, logical, to coincidental.
- Dependency inversion principle
- High-level modules should not depend on low-level modules; both should depend on abstractions, and abstractions should not depend on implementation details.
- Quality attribute scenario
- A six-part specification of a quality requirement: stimulus, source, environment, artifact, response, and response measure, used to evaluate architecture fitness.
- Cyclomatic complexity
- A count of linearly independent paths through code, computed as edges minus nodes plus twice the connected components, indicating test effort and refactoring need.
- Defensive programming
- A construction practice that validates inputs at trust boundaries, fails fast on invalid state, and uses assertions for internal invariants rather than for user input.
- Refactoring
- A behavior-preserving transformation of code structure that improves readability or design without changing observable functionality, performed in small steps under automated tests.
- Immutability
- A property of objects whose state cannot change after creation, which eliminates a class of concurrency and aliasing defects and simplifies reasoning about code.
- Verification versus validation
- Verification confirms the product was built according to its specification; validation confirms the specification reflects what the user actually needed.
- Boundary value analysis
- A black-box technique that selects test inputs at and around the edges of valid input ranges, where off-by-one defects concentrate.
- Equivalence partitioning
- A technique dividing inputs into classes expected to behave identically, so a single representative value per class suffices for testing.
- MC/DC coverage
- Modified condition/decision coverage requires each condition to independently affect a decision outcome at least once, stronger than branch coverage and used in safety-critical software.
- Regression testing
- Re-execution of a selected subset of existing tests after a change to confirm that previously working behavior remains intact and no new defects were introduced.
- Lehman's laws of evolution
- Empirical observations that evolving software must continually change, grows in complexity unless maintained, and declines in quality without preventive work.
- Technical debt
- The accumulated cost of expedient design or code choices, where interest is paid as slower future change and principal is the effort to remediate.
- Perfective maintenance
- Maintenance that improves performance, maintainability, or other attributes in response to new user needs rather than correcting faults or adapting to environment changes.
- Impact analysis
- The process of identifying which artifacts, tests, and components are affected by a proposed change, used to scope regression testing and estimate ripple cost.
- Baseline
- A formally reviewed and approved configuration snapshot that can only be changed through an approved change control procedure.
- Defect removal efficiency
- The ratio of defects found before delivery to the total defects found before and after delivery, measuring how well quality activities filter defects.
- Configuration audit
- A review verifying that delivered artifacts match their documented baselines and that change control records are complete and consistent.
- Critical path method
- A scheduling technique identifying the longest-duration dependency path, whose zero-float activities determine the minimum project duration.
- Cost performance index
- Earned value divided by actual cost; a value below one indicates the project has spent more than the value earned to date.
- COCOMO II
- A parametric estimation model computing effort from size raised to an exponent scaled by process factors and multiplied by cost driver multipliers.
- Brooks's Law
- The observation that adding personnel to a late software project delays it further because of communication overhead and ramp-up time for new members.
- V-model
- A lifecycle model pairing each development phase with a corresponding verification phase, such as requirements with acceptance testing and detailed design with integration testing.
- Spiral model
- A risk-driven iterative lifecycle in which each cycle performs objective setting, risk analysis, engineering, and evaluation before proceeding to the next spiral.
- Threat modeling with STRIDE
- A structured analysis classifying threats as Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege, performed during design.