CPSA Risk Management and Technical Debt

Question 1

What is the primary definition of technical debt in software architecture?

Accepted Answer

The cost of rework caused by choosing an expedient solution now instead of a better approach

Answer

The financial cost of software licenses accumulated over time

Answer

The number of unresolved bugs in a system

Answer

The time required to train new developers on the codebase

Question 2

Which of the following is an example of INTENTIONAL technical debt?

Accepted Answer

A team deliberately skips unit tests to meet a release deadline with a plan to add them later

Answer

A developer unknowingly violates an architectural rule due to lack of experience

Answer

Duplicate code introduced by a contractor who was unaware of existing modules

Answer

Security vulnerabilities introduced because developers did not read the documentation

Question 3

What is architectural risk in the context of software architecture?

Accepted Answer

Uncertainty about whether the architecture will satisfy required quality attributes under real-world conditions

Answer

The probability that a project will exceed its budget

Answer

The risk that a developer will leave the project before completion

Answer

The chance that requirements will change after development begins

Question 4

What is architecture erosion?

Accepted Answer

The gradual divergence between the intended architecture and the implemented system

Answer

The process of deliberately removing outdated components from a system

Answer

A planned simplification of a complex architecture over multiple releases

Answer

The reduction of system performance due to increased load over time

Question 5

Which tool or method is most commonly used to assess and quantify technical debt in a codebase?

Accepted Answer

Static code analysis tools such as SonarQube

Answer

Gantt charts

Answer

Network diagrams

Answer

Entity-Relationship diagrams

Question 6

What is a 'Big Ball of Mud' in software architecture?

Accepted Answer

A haphazardly structured system with no discernible architecture, often the result of accumulated technical debt

Answer

A design pattern for highly scalable distributed systems

Answer

A database schema with many redundant tables

Answer

A microservices architecture with too many services

Question 7

Which strategy is BEST for systematically reducing technical debt without disrupting ongoing feature development?

Accepted Answer

Allocate a fixed percentage of each sprint or iteration to debt reduction activities

Answer

Halt all feature development until all debt is resolved

Answer

Ignore the debt and let it resolve itself over time

Answer

Rewrite the entire system from scratch on a fixed deadline