PE Software: Configuration Management and Maintenance

What this domain tests

This domain checks whether you can keep a changing product under control: identifying configuration items, controlling change, proving what shipped, and classifying maintenance work correctly. Expect baseline discipline, version control workflow, and the maintenance taxonomy.

Core rules and concepts

• Configuration management has four functions: identification (items, versions, baselines), control (change requests, change control board), status accounting (records of what was done and what is in each build), and audit (configuration audit versus functional/physical audit).
• A baseline is an approved, fixed reference: requirements baseline, design baseline, code baseline, product baseline. After baselining, change happens only through an approved change request.
• Maintenance categories: corrective (fixing defects), adaptive (responding to a changed environment such as an OS, database, or regulation), perfective (new or improved user requirements), preventive (reducing future deterioration, for example refactoring or adding tests).
• Reverse engineering recovers design information from code; reengineering combines reverse engineering with forward engineering to restructure a legacy system; refactoring is small-scale behavior-preserving restructuring at code level.
• Reproducible builds and immutable release artifacts are what make auditing possible at all.

Worked example

A defect appears in production. Trace it through the CM functions.

1. The tester logs the defect with the exact product version and build identifier: identification.
2. A change request is raised and the change control board assesses impact and approves: control.
3. The developer branches from the release baseline, commits the fix plus a regression test, and obtains peer review: control, at a finer grain.
4. The branch is merged, the build is regenerated, and the full regression suite runs.
5. Records show which change requests are contained in the patch release: status accounting.
6. Reviewers confirm the release contains only approved changes and that documentation matches the artifact: configuration audit. Reasoning: each step maps to exactly one CM function, and skipping the branch would let unrelated in-flight work ship with the fix.

Traps that cost marks

• Calling all maintenance corrective; in practice perfective work dominates the effort profile.
• Confusing adaptive (environment change) with perfective (new user requirement).
• Fixing a production defect on the mainline so it silently rides along with other changes.
• Treating reverse engineering as identical to reengineering.