This scenario describes Refactoring. SBOK defines refactoring as improving the internal design or structure of existing software while preserving its externally observable functionality. The objective is to make code more concise, maintainable, flexible, and understandable without changing what the software does.
The scenario specifically states that the existing implementation is complex, redundant, and time-consuming to maintain, while functionality must remain intact. Those are classic refactoring conditions. Typical refactoring work can include eliminating duplicated code, simplifying overly complicated logic, separating responsibilities, improving naming and structure, and reducing unnecessary coupling.
Design Patterns differ because they provide reusable documented solutions to recurring design problems. A team might employ a design pattern while refactoring, but “Design Patterns” does not describe the overall activity of restructuring existing code without changing behavior.
Mitigated Risks and Updated Dependencies are project-management outputs rather than software-engineering techniques for internal code improvement.
Therefore, the defining combination—redesign internal code, remove redundancy, improve maintainability, preserve functionality—identifies refactoring unambiguously.
Study Guide reference: Quality/Implement - > Create Deliverables - > Refactoring; technical practices for maintaining product quality.
========
