SDLC phases
- Planning / feasibility — business case, scope, cost-benefit
- Analysis — gather and document requirements
- Design — architecture, data model, controls designed in, not bolted on
- Development — build and unit test
- Testing — system, integration, and user acceptance testing (UAT)
- Implementation — data conversion and cutover
- Maintenance — ongoing fixes and enhancements
IMPORTANT: Testing must occur in a separate test environment using data that does not expose sensitive production information. Testing in production, or copying live personal data into test without masking, are both classic findings.
Conversion approaches
| Approach | Risk profile |
|---|---|
| Parallel — run old and new together | Lowest risk, highest cost |
| Phased — implement in stages | Moderate risk, longer timeline |
| Pilot — one location or unit first | Contained risk, limited early validation |
| Direct cutover ("big bang") | Highest risk, lowest cost — no fallback if it fails |
Methodologies
- Waterfall — sequential, heavy documentation; works when requirements are stable
- Agile — iterative sprints, continuous user feedback; adapts to changing requirements but demands disciplined change control to stay auditable
- DevOps — integrates development and operations with automated pipelines; requires automated controls (approval gates, automated testing) because deployment frequency is high
Change management controls
- Formal request, business approval, documented testing, and separate approval to migrate
- Segregation between the person who writes the change and the person who moves it to production
- Emergency changes — permitted, but must be logged and retroactively reviewed and approved
- Version control and the ability to roll back
EXAM TIP: In an agile or DevOps environment, controls don't disappear — they become automated and embedded in the pipeline (automated test gates, required peer approval on merge, immutable deployment logs).