Inspiration, not blueprint
Where the idea came from
The EDLC borrows a habit from software teams, who learned to treat the whole life of a system as the thing they design. It borrows the habit, not the vocabulary or the assumptions.
Education already has strong design models. ADDIE, backward design, constructive alignment and iterative models such as SAM all describe how to build a program well. What they say little about is what happens after release: how a program is versioned, observed, repaired and improved across many cohorts.
Software engineering faced a similar gap and closed much of it with lifecycle practices. The table below records the parallels that shaped the EDLC. It is here for readers who know software; nothing in the model depends on it.
| Software practice | Education equivalent in the EDLC | Stage |
|---|---|---|
| Requirements specification | Learning standard (unit, outcome set, capability standard) | 2 Specify |
| User research and personas | Learner needs analysis and cohort profiles | 1 Discover |
| Traceability matrix | Mapping matrix linking outcomes to assessment and delivery | 3 Architect |
| Architecture review | Coverage and assessment strategy review | 3 Architect |
| Scaffolding and interface stubs | Structural skeleton of all deliverables | 4 Scaffold |
| Test-driven development | Assessments and marking guides written before content | 5 Test-first |
| Test fixtures and staging environments | Simulated workplace or case-study context | 5 Test-first |
| Implementation | Learning materials and activities | 6 Build |
| Release planning | Session or module plan within timetable constraints | 7 Orchestrate |
| Code review | Peer, subject-matter expert and compliance review | 3 to 8 |
| Release and certification | Pre-use validation and versioned release | 8 Validate and release |
| Production monitoring | Learning and assessment analytics | 9 Deliver and observe |
| Incident management | Complaints, appeals and assessor disputes | 9 Deliver and observe |
| Retrospective and post-incident review | Post-use validation | 10 Improve |
| Dependency upgrade | Revision of the upstream standard | 10, re-entering 2 |
| Technical debt | Curriculum debt | 10 Improve |
The rows follow the paper's mapping (section 4.2). Some parallels are looser than others: writing assessments first is closer to defining acceptance criteria before building than to the developer-level cycle of test-driven development.
Where the comparison stops
Learners are people, not systems, and the comparison breaks in at least six places. Each break became a guardrail in the model. The paper's section 7 sets out the reasoning.