Systems Development Life Cycle Phases for the Developer Exam

The systems development life cycle in four phases

The systems development life cycle is the sequence of phases an IT system passes through from first idea to eventual retirement. For the Claude Certified Developer - Foundations (CCDV-F) exam, task statement 2.2 frames it in four phases you should be able to name on demand: development, implementation, operation, and maintenance. This is a remember-level knowledge point, so the exam expects you to recall the phases and what each one is for, and to understand that a Claude project moves through them like any other system rather than inventing a new process of its own.

The value of holding these four phases clearly is that they organise every other idea in the domain. Requirements analysis, the subject of functional requirements for Claude solutions, lives in development. Deployment lives in implementation. Monitoring lives in operation. Managing model updates and drift lives in maintenance. Get the phases straight and the rest of the life-cycle material has a place to hang.

What each phase delivers

Each phase carries its own deliverables, and knowing them is most of what this knowledge point asks. Development is where you establish requirements and design and build the system, so its deliverables are the requirements, the design, and the working artefacts, prompts, tools, and configuration among them for a Claude system. Implementation is where the built system is deployed into its target environment, so its deliverable is a running, released system rather than a design on paper.

Operation is where the deployed system runs in service, and its deliverable is ongoing monitoring: watching that the system continues to meet the quality, cost, and latency targets it was built against. Maintenance is where the system is sustained over time, and its deliverables are the updates that keep it healthy, model version changes, prompt revisions, and dependency upgrades, along with the revalidation those changes require. The phases run in order but they are not one-way; maintenance regularly loops back into development-style work when a change is significant.

Claude work maps onto the phases, it does not replace them

The most important idea in this knowledge point, and the one the exam most wants you to internalise, is that building with Claude does not exempt a project from the life cycle. A Claude application still needs requirements and design in development, a real deployment in implementation, monitoring in operation, and sustained upkeep in maintenance. The presence of a model does not collapse those phases or make them optional; it simply adds AI-specific concerns inside each one.

This is why the first exam trap is treating an AI project as exempt from normal life-cycle discipline, as if prompting a capable model were a substitute for engineering process. It is not. The mapping view is the corrective: rather than a parallel universe, a Claude project is the ordinary life cycle with model-shaped deliverables in each phase. That framing sets up the two knowledge points this one unlocks, operating and maintaining Claude systems, which lives in the operation and maintenance phases, and integrating Claude into an existing SDLC, which fits Claude work into an established process.

Do not skip maintenance

The second trap is subtler and specific to AI systems: skipping the maintenance phase, or treating it as an afterthought. It is tempting because a freshly launched Claude system that passes its evals feels finished. But the maintenance phase is exactly where model updates, prompt changes, and dependency upgrades are handled, and on an AI platform those are not rare events. Model behaviour can shift across releases, so a system left unmaintained can drift away from the targets it launched with even if no one touches the code.

For a remember-level exam this shows up as recognising that maintenance is a first-class phase with real deliverables, not a bucket for occasional bug fixes. The deeper treatment of what maintenance actually involves, monitoring for drift, revalidating after model updates, and managing cost regressions, belongs to the next knowledge point, but you should already be able to say that maintenance exists, that it is where model and dependency changes are managed, and that leaving it out is a defining life-cycle mistake for AI work.

Common misreadings to avoid

How this is tested on the CCDV-F exam

Questions on this knowledge point are recall and recognition. You might be asked to name the phases, to match a deliverable to its phase, or to identify which phase a described activity belongs to. The two things the exam trips candidates on are the belief that AI projects sit outside the normal life cycle and the omission of the maintenance phase. If you can list the four phases, say what each delivers, and assert that Claude work maps onto rather than replaces them, you have this knowledge point.

Once the phases are secure, the domain moves into the two that carry the most AI-specific weight: what it takes to run a live Claude system in operating and maintaining Claude systems, and how to fold Claude development into an established process in integrating Claude into an existing SDLC.