The V-model is the cliché everyone hides behind. ASPICE never mandated waterfall — and agile sprints, CI/CD, and AI agents can fill the V with continuous, traced evidence.
ASPICE does not require waterfall. The V-model it is built around describes dependencies and traceability between engineering activities (requirements → architecture → design → code, verified back up) — not the order in time you must do them in. You can satisfy every ASPICE process area inside agile sprints: each increment carries its slice of the V-model, and traceability is maintained continuously instead of reconstructed at the end. The waterfall association is a widespread misreading of the model.
“ASPICE means waterfall, so we can't be agile.” It's the most repeated excuse in automotive software — and it's wrong. Let's kill it properly.
The tired mental image is a rigid left-to-right march: specify everything, then design everything, then code, then test. But the V-model is a shape, not a schedule. Its two arms express traceability: system requirements (SYS.2) → software requirements (SWE.1) → detailed design (SWE.3) down the left; unit, integration, and qualification verification (SWE.4 → SWE.6 → SYS.5) up the right. What the V encodes is which artifact must trace to which — not what you must finish before you're allowed to start the next thing.
ASPICE was born in the 1990s, when ECUs ran a few hundred thousand lines of C and heavyweight up-front specs were the norm. Assessors asking for “formally approved requirements before code” got cargo-culted into hard phase gates. But ASPICE grades whether the work products and traceability exist and are consistent — not whether you produced them in one big pass. The standard is agnostic about iteration; the bloated processes built on top of it are not.
Because what they've actually seen is waterfall — the enormous process someone built off the model. Teams take the 130-page assessment model and build a build-manual out of it, and then the ceremony begins:
“Not formally approved requirements? Big deviation. No formally reviewed UML detailed design before coding? Wrong again. Changed some code without filing a change request, doing the impact analysis, and getting Change Control Board approval? Hold on.”The deviation litany, from real assessments
That ceremony — not the V-model — is what kills agility. It comes from treating an assessment framework like a build manual, and it's optional.
Here's the honest root cause. Legacy ASPICE practice assumes you can specify everything up front and it will hold. Modern software embraces the opposite — you learn by building, and requirements change. So the real enemy of agility was never the V-model. It's late, manual, after-the-fact evidence. Fix that, and the V-model and agile stop fighting. Tesla is the existence proof that agility plus automation can match or beat heavyweight process — the key is measuring everything, leveraging AI, and keeping engineers in control.
Small increments, each carrying a traced slice of the V: requirements (SWE.1), architecture (SWE.2), detailed design (SWE.3), and verification (SWE.4–6) evolving together within the sprint, with change management (SUP.10) done lightweight instead of as a bureaucratic gate. Traceability is maintained as you go, not reconstructed in a panic before the assessment. Done this way, agile teams absolutely can reach CL2 and CL3.
This is where it becomes practical. Wire AI agents into the pipeline, and on every pull request they run the end-to-end change analysis — requirements impact → architecture → design → test cascade — with a confidence score and audit trail, and post it for a human to approve. Compliance stops being a project you do before SOP; it becomes continuous. That's how you get Tesla-speed iteration and an OEM-auditable V-model. It's exactly what Vera does.
“Compliance stops being a project. It becomes continuous.”On CI/CD-native ASPICE
No. ASPICE is built around the V-model, which describes traceability between engineering activities, not the order in time you must perform them. Nothing in ASPICE mandates a waterfall lifecycle.
Yes. Each increment carries a traced slice of the V-model — requirements, architecture, design, and verification evolving together — with traceability maintained continuously. Agile teams can and do reach Capability Level 2 and 3.
No. The V-model is a shape that expresses dependencies and bidirectional traceability between artifacts. Waterfall is a scheduling choice. You can realize the V-model iteratively.
By maintaining links as work is produced rather than reconstructing them at the end — ideally generated automatically. AI agents wired into CI can trace requirements → architecture → design → tests on every pull request, with confidence scores and an audit trail.
Yes. The capability levels grade whether work products are managed (CL2) and the process is established across the organization (CL3) — both achievable with agile increments, provided the evidence and traceability are consistent and current.
Grounded in the standard, honest about the theater: What is ASPICE · Automating ASPICE with AI agents · ASPICE vs CMMI · Best ASPICE tools