Risk Management and Technical Debt Flashcards
7 cards from real CPSA practice questions. Tap to flip, then mark Knew It or Still Learning — missed cards come back until you master them.
Read the first 7 Risk Management and Technical Debt flashcards as text
What is the primary definition of technical debt in software architecture?
Answer: The cost of rework caused by choosing an expedient solution now instead of a better approach
Technical debt refers to the implied cost of future rework required when a quick or suboptimal solution is chosen over a better long-term approach.
Which of the following is an example of INTENTIONAL technical debt?
Answer: A team deliberately skips unit tests to meet a release deadline with a plan to add them later
Intentional technical debt is knowingly incurred, such as skipping tests to meet a deadline, with the explicit plan to address it later.
What is architectural risk in the context of software architecture?
Answer: Uncertainty about whether the architecture will satisfy required quality attributes under real-world conditions
Architectural risk specifically concerns uncertainty about whether the chosen architecture can meet the system's quality attribute requirements.
What is architecture erosion?
Answer: The gradual divergence between the intended architecture and the implemented system
Architecture erosion occurs when the actual implemented system drifts away from the originally designed and documented architecture.
Which tool or method is most commonly used to assess and quantify technical debt in a codebase?
Answer: Static code analysis tools such as SonarQube
Static code analysis tools like SonarQube measure code quality metrics, rule violations, and provide a technical debt ratio to quantify accumulated debt.
What is a 'Big Ball of Mud' in software architecture?
Answer: A haphazardly structured system with no discernible architecture, often the result of accumulated technical debt
A Big Ball of Mud describes a system that has grown without a coherent architecture, typically due to years of unmanaged technical debt and ad-hoc changes.
Which strategy is BEST for systematically reducing technical debt without disrupting ongoing feature development?
Answer: Allocate a fixed percentage of each sprint or iteration to debt reduction activities
Allocating a consistent portion of each iteration to debt reduction balances new feature delivery with gradual improvement of the codebase.