Lesson 3: The Computational Modelling Lifecycle

1 Modelling context

Lessons 1 and 2 decided what kind of model you are building and whether randomness belongs in it. Neither answers the question of how the work proceeds. That is the subject of this lesson.

A computational modelling project is not a single act of computation. It is a sequence of decisions, each of which constrains the next and each of which must be recorded if the result is to be reproducible. The fourteen-step lifecycle below is the sequence used throughout MATH 4810. It is not a rigid procedure to be followed mechanically; it is a structure for making modelling decisions explicit and their consequences traceable.

The lifecycle reappears in every module. Modules 2 through 6 each exercise a subset of it in depth. Module 7 and the capstone exercise it end to end.

Why a lifecycle at all

Without a stated process, modelling decisions are made implicitly and cannot be examined. The purpose of the lifecycle is not to standardise the answer, but to standardise the record of how the answer was reached.

2 Learning objectives

By the end of this lesson you will be able to

List the fourteen steps of the computational modelling lifecycle and explain the purpose of each.
Group the steps into the four phases and describe the transition between phases.
Distinguish calibration, verification, and validation within the cycle.
Identify where iteration is expected and explain why iteration is not a failure.
Apply the lifecycle to a small system and produce a one-page modelling plan.

3 Prerequisite review

System boundary: The line between what the model represents internally and what it treats as given from outside. Introduced in Lesson 1 as part of the classification exercise.
Claim-support scope: The statement of what a model can and cannot be used to claim. Introduced in Lesson 1 and revisited throughout the course.
Sample path and replication: Concepts from Lesson 2. The lifecycle treats replication as part of the experimental design stage, not as an afterthought.
Reproducibility: The property that another analyst, given the same inputs, files, and documented procedure, obtains the same results. The lifecycle is the mechanism by which this property is achieved.

4 The fourteen steps

The steps are listed in the order in which they are normally first encountered. In practice the process is not linear: the cycle is repeated, and later steps frequently send you back to earlier ones. The ordering is a guide to dependency, not a schedule.

Define the question and model purpose State what decision or understanding the model must support. This is the anchor for every subsequent decision.
Establish the system boundary Decide what is inside the model and what is treated as external. State why the boundary falls where it does.
Define variables, parameters, units, and assumptions Make every quantity explicit and dimensionally consistent. Document each assumption, however small.
Select the modelling approach Deterministic or stochastic, static or dynamic, analytical or numerical. Justify the choice with reference to the question.
Choose a numerical or simulation method Match the method to the structure, scale, and required accuracy of the problem.
Implement the model Build a transparent spreadsheet or code architecture, following the conventions in Unit 1.2.
Verify formulas, code, and model logic Confirm the implementation matches the intended specification. Verification does not use the real-world data.
Test numerical stability and convergence Vary step size, grid, or replication count deliberately and record the effect on the output.
Validate the model against evidence or known behaviour Compare with data, analytical solutions, or limiting cases. State what would count as disconfirming evidence.
Conduct uncertainty and sensitivity analysis Identify which inputs actually drive the outputs, and by how much.
Compare scenarios Run designed experiments rather than one-off trials. State the scenario design before running it.
Interpret limitations State what the model cannot tell you, and under what conditions it would stop being useful.
Communicate findings Write for both technical and non-technical readers. The executive summary is a deliverable, not a courtesy.
Archive reproducible model files Leave a trail another analyst could rerun, including seeds, versions, and dependencies.

Reading the list

Note the position of verification (step 7) relative to validation (step 9). Verification comes first: there is no point asking whether a model represents reality well if it does not even compute what you specified.

5 Four phases

The fourteen steps group naturally into four phases. The phases are cyclic, not sequential: in a real project you will move through them more than once.

Figure 1.5. The four phases of the modelling lifecycle. The arrows are clockwise, and the cycle repeats — a real project passes through these phases more than once.

What each phase produces

Formulate produces the model specification: the purpose, boundary, variables, parameters, assumptions, and chosen method. Nothing is implemented yet.
Implement produces a runnable model with a documented architecture. Nothing is claimed about its correctness yet.
Test produces the evidence: verification results, convergence checks, validation comparisons, sensitivity analyses, and scenario outputs.
Communicate produces the deliverables: the technical report, the plain-language summary, the presentation, and the archived model files.

6 Worked example

Applying the lifecycle to the spread of a rumour

A small closed community of 200 people. A rumour starts with one person. You are asked to model how many people have heard it after one week.

Define the question. The decision is whether to intervene with a counter-message. The model must estimate the number of informed people over time and the sensitivity of that number to the transmission rate.
Establish the boundary. Inside: the 200 community members. Outside: contact with anyone outside the community, and any behaviour change that would not occur in an ordinary week.
Define variables, parameters, units, assumptions. State variable I(t): number informed at time t. Parameter β: transmission rate per informed–uninformed contact pair, with units of inverse days. Assumptions: closed population, homogeneous mixing, no forgetting, no re-transmission by the uninformed.
Select the approach. A deterministic compartmental model. The question concerns the average trajectory in a large community, not the tail behaviour in a small one. A stochastic model would be appropriate if the community were small enough for extinction events to matter, but at 200 members the mean-field approximation is defensible.
Choose a numerical method. The model is an ODE system, so a standard one-step solver (fourth-order Runge–Kutta) is sufficient. The method and its step size are documented.
Implement. A spreadsheet with inputs, calculations, and outputs in separate regions, following the Unit 1.2 conventions.
Verify. Check that the total population is conserved at every step. Check that the derivative is zero at the equilibrium. Compare against the analytical solution on a small interval where one is tractable.
Test stability and convergence. Halve the step size and confirm that the output changes less than a stated tolerance. Document the observed convergence order.
Validate. Compare against a classroom demonstration, a documented case study, or the observed dynamics of a rumour in a comparable setting. State in advance what result would count as disconfirming evidence.
Uncertainty and sensitivity. Vary β across a plausible range and plot the resulting curves. Determine whether the decision changes over that range.
Compare scenarios. A counter-message that halves β at day 2 versus day 4. Report the difference in peak informed count.
Interpret limitations. The model assumes homogeneous mixing, which is false in most communities. It cannot represent network structure. It does not model forgetting.
Communicate. A technical report for the analyst and a one-page summary for the decision-maker, stating the estimated curve, the sensitivity to β, and the limitations.
Archive. The spreadsheet, the parameter values, the step size, the version of the software used, and the scenario definitions.

At several points the process would send you back. If verification shows that population is not conserved, you return to step 6. If validation fails, you return to step 4 or 5. This is normal.

7 Evidence at each stage

Each stage of the lifecycle produces evidence that a reader can examine. The following table pairs a selection of stages with the evidence expected at the end of the stage.

Evidence produced by each lifecycle stage
Stage	Evidence
1. Purpose	A written statement of the question and the decision the model must support.
2. Boundary	A list of what is inside and outside, with a justification for each exclusion.
3. Variables and assumptions	A table of variables, parameters, units, and assumptions, each with a source or justification.
6. Implementation	A runnable model file with a documented three-layer architecture.
7. Verification	Tests that the implementation matches the specification, such as conservation checks or analytical comparison on a tractable subcase.
8. Convergence	A table or plot showing the output as a function of step size or replication count, with the chosen value justified.
9. Validation	A comparison with data, analytical results, or limiting cases, and a statement of what would have disconfirmed the model.
10. Sensitivity	A plot or table of output against each key input, with the dominant drivers identified.
13. Communication	A technical report and a plain-language summary, both stating assumptions and limitations.
14. Archive	Model files, inputs, seeds, software versions, and a readme sufficient for another analyst to rerun the project.

8 Iteration and limitations

The lifecycle is drawn as a cycle for a reason. In a real project you will move through it more than once, often returning to an earlier stage when a later one reveals a problem. Three sources of iteration are especially common:

Verification failure. The implementation does not match the specification. Return to step 6 and fix it. Do not proceed to validation.
Validation failure. The model does not reproduce the evidence. Return to step 4 and reconsider the modelling approach, or to step 3 and reconsider the assumptions. Do not simply adjust parameters until the fit improves — that is not validation.
Sensitivity surprise. The output turns out to depend strongly on a parameter you had treated as fixed. Return to step 3 and model the parameter explicitly, or to step 4 and consider a stochastic formulation.

Iteration is not a sign that the project is going badly. It is a sign that the process is working. What matters is that the path is documented: a reader should be able to see which stages were revisited and why.

The lifecycle is not a checklist

Treating the fourteen steps as a box-ticking exercise defeats the purpose. The point of the lifecycle is to make each decision explicit and its consequences traceable, not to produce a document with fourteen headings.

9 Common implementation errors

Watch for these

Treating the cycle as linear. Modelling is iterative. A project that runs straight through in one pass is either trivial or has skipped a stage.
Skipping documentation until the end. The decisions that matter most are the ones made in the moment. Record them as you make them; retrospective documentation is usually incomplete.
Conflating verification with validation. Step 7 and step 9 are different activities. Verification asks whether the implementation matches the specification. Validation asks whether the model represents the real system well enough for its purpose.
Running one-off trials instead of designed experiments. Step 11 expects a scenario design, not a set of arbitrary runs.
Archiving files without the accompanying documentation. A model file with no readme, no recorded seeds, and no version information is not reproducible, even if it runs.
Adjusting parameters until the fit improves and calling it validation. This is calibration repeated until the model memorises the data. It does not constitute evidence that the model represents the system.

10 Independent modelling task

Your turn

Choose a system. It can be small — a household process, a classroom dynamic, a public service, a simple physical system.
Produce a one-page modelling plan that walks through all fourteen stages. For each stage, write one or two sentences. Where you do not yet know the answer, state what you would need in order to decide.
Identify at least two places where iteration is likely and explain what would trigger the return.
List the evidence you would present at steps 7, 8, and 9 — verification, convergence, and validation — for this specific system.
Write the sentence you would use to state the model's claim-support scope.

This plan is the basis for Assignment 1. Bring it to the assignment with the classification exercise from Lesson 1 and the deterministic/stochastic comparison from Lesson 2.

11 Reflection prompt

Reflect before continuing

Of the fourteen stages, which one do you habitually skip or rush?

Then consider what skipping it has cost you in past work — a decision you could not defend, a result you could not reproduce, a model that nobody else could use. Two or three sentences. The point is not to change your habits today, but to notice them.

12 Lesson summary

Key takeaways

The lifecycle has fourteen steps, grouped into four phases: Formulate, Implement, Test, Communicate.
Verification precedes validation. There is no point asking whether the model represents reality if the implementation does not compute what you specified.
Iteration is expected. The cycle repeats, and revisiting earlier stages is a sign that the process is working.
Each stage produces evidence. A defensible model can point to what was done at every step and what it showed.
Documentation is continuous. Decisions are recorded as they are made, not reconstructed afterwards.

Unit 1.1 complete

You have classified models, decided whether randomness belongs in them, and learned the process by which they are built. Unit 1.2 turns to the physical construction of the model: the architecture that makes it inspectable, the estimation of its parameters, and the separation of verification, validation, and reproducibility.

§ Self-quiz, practice, and homework

Practice exercises

For the rumour-spreading example, identify which step of the lifecycle each of the following decisions belongs to: (a) deciding to model a closed population; (b) selecting fourth-order Runge–Kutta; (c) comparing against a classroom demonstration; (d) writing the executive summary.
For each of the four lifecycle phases, name one specific deliverable.
Describe a project you have worked on where an early decision had to be revised later. Identify which step of the lifecycle the revision corresponds to.
Write a two-sentence justification for starting with step 1 rather than step 4 of the lifecycle.

Homework problems

Full lifecycle walk-through. Choose a system you know well. Walk through all fourteen steps of the lifecycle for that system. For each step, write two to three sentences stating what you would do and why. Conclude with a claim-support statement. Total length: 1000–1500 words.
Evidence plan. For the same system, produce an evidence table listing what you would present at steps 7, 8, 9, 10, and 11. For each, state the specific test or analysis and the acceptance criterion.
Iteration analysis. Identify three points in your lifecycle plan where iteration is likely. For each, describe the trigger (what would send you back), the step you would return to, and what you would change.

Mini project

Produce a one-page "modelling plan" for a system of your choice, structured as a table with one row per lifecycle step. Include: the step, the decision made, the evidence produced, and the criterion for success. Submit as a PDF. This plan should be the basis for your Assignment 1 project.