Lesson 3: Simulation Capstone Integration

1 Modelling context

The capstone is not a single technique applied to a single problem. It is a modelling project that exercises the full lifecycle: purpose, boundary, formulation, implementation, verification, validation, sensitivity, scenarios, interpretation, communication, and archive. Each of these stages has been addressed in previous modules; the capstone requires them to be assembled into a coherent whole.

This lesson addresses the integration task directly. It covers how to plan the project, how to sequence the work, how to manage the iteration that is inherent in any real project, and how to produce an archive that makes the project reproducible. The lesson is not content-heavy in the mathematical sense; it is about the practice of delivering a modelling project end to end.

The capstone is a project, not a puzzle

A capstone is measured by the quality of the process as much as by the quality of the result. A well-executed project with a modest finding is more valuable than a poorly documented project with an impressive-sounding conclusion.

2 Learning objectives

By the end of this lesson you will be able to

Plan a capstone project against the fourteen-step modelling lifecycle.
Sequence the work so that dependencies are respected.
Manage the iteration that occurs when later steps inform earlier ones.
Assemble a reproducibility package for the project.
Self-assess the project against the capstone rubric.
Identify the components of the capstone that require the most time and prioritise them.

3 Prerequisite review

Modelling lifecycle: The fourteen-step process introduced in Module 1. The capstone exercises all fourteen steps.
Reproducibility package: The set of files, documentation, and metadata required for another analyst to rerun the project. Includes model files, inputs, seeds, software versions, and procedure.
Iteration: The process of revisiting earlier stages of the lifecycle when later stages reveal problems or new information. Expected and normal in a real project.
Claim-support statement: The final statement of what the model can and cannot be used to claim, based on the evidence produced.

4 Integrating the cycle

Sequencing the work

The fourteen steps are not a linear sequence. The following ordering respects the natural dependencies and is a practical plan for a capstone project.

Define the question and purpose What decision does the model support, and what does it need to say?
Write the project proposal Scope, deliverables, timeline, and success criteria.
Establish the system boundary and identify the modelling approach What is inside the model, what is outside, and which method (ODE, PDE, Monte Carlo, DES, LP) is appropriate?
Define variables, parameters, units, and assumptions Before any implementation, the specification must be written down.
Source or construct the data Calibration data, validation data, and input distributions.
Implement the model Following the three-layer architecture from Module 1.
Verify the implementation Analytical comparison, limiting cases, conservation, convergence.
Validate against held-out data With disconfirming evidence stated in advance.
Conduct sensitivity and uncertainty analyses Which inputs matter, and what is the output distribution?
Design and run scenario experiments Factorial or OFAT design, as appropriate to the question.
Interpret results and state limitations What the model says, what it does not, and under what conditions.
Write the technical report and executive summary Two documents for two audiences.
Prepare the presentation Accessible, one idea per slide, for a non-technical audience.
Assemble and archive the reproducibility package Files, documentation, seeds, and versions.

Iteration

In practice, the project will iterate. Common triggers:

Verification failure. Return to step 6 (implementation).
Validation failure. Return to step 4 (assumptions) or step 3 (approach).
Sensitivity surprise. Return to step 3 or 4 to reconsider the model structure.
Scenario results that suggest a new question. Return to step 1 or 2.

Document the iterations. A reader should be able to see which steps were revisited and why.

The reproducibility package

The archive is a first-class deliverable. It should contain:

The model files. The spreadsheet or code used to produce the results.
The data. Calibration data, validation data, and any external inputs. Include a description of the source and any transformations applied.
The seeds. The random seeds used, including which seed applies to which replication or scenario.
The software versions. The version of the spreadsheet or programming environment, and any add-ins or libraries.
The procedure. A readme describing how to run the model, including any manual steps and the order of operations.
The outputs. The results as recorded, including the figures and tables that appear in the report.

Figure 7.8. The reproducibility package. Six categories of content, all required for the project to be reproducible by another analyst.

5 Worked example

Integration plan for a capstone project

A student is undertaking a capstone on the effect of staffing levels on waiting times in a walk-in clinic. The following plan walks through the integration.

Step 1 — The question.

How many nurses should the clinic employ to keep the 90th-percentile patient wait below 20 minutes during peak hours?

Step 2 — Proposal.

Deliverables. Model, verification report, validation report, sensitivity analysis, scenario study, technical report, executive summary, presentation.
Timeline. 8 weeks. Weeks 1–2: specification and data. Weeks 3–4: implementation and verification. Weeks 5–6: validation, sensitivity, scenarios. Weeks 7–8: report and presentation.
Success criteria. Model validated against held-out data within stated tolerance; sensitivity analysis identifies the dominant inputs; scenario study produces a staffing recommendation with a 95% interval.

Step 3 — Boundary and approach.

Inside: patient arrivals, triage, nurse staffing, examination rooms. Outside: laboratory services, pharmacy, external referrals. Approach: discrete-event simulation, because the question concerns waiting times and queue dynamics.

Step 4 — Variables and assumptions.

Arrival process: non-homogeneous Poisson with rate estimated from historical data.
Service time: log-normal, estimated from observation.
Nurse count: 3, 4, 5 (scenario factor).
Assumption: no abandonment (patients do not leave without being seen).
Assumption: triage time is negligible relative to wait time.

Step 5 — Data.

Eight weeks of arrival timestamps and service durations from the clinic's electronic records. Split: first six weeks for calibration, last two weeks for validation.

Step 6 — Implementation.

Discrete-event simulation in a spreadsheet, following the event-calendar structure from Module 5. Three-layer architecture: inputs, calculations, outputs.

Step 7 — Verification.

Analytical comparison: M/M/c formulas for a simplified case.
Conservation check: every arrival has a matching departure.
Limiting case: zero arrivals should produce zero queue.
Convergence: increasing replications should stabilise the mean wait.

Step 8 — Validation.

Compare the model's predicted mean wait against the observed wait in the two held-out weeks. Disconfirming evidence stated in advance: mean wait predicted more than 15% off the observed mean, or systematic bias in the residuals over time of day.

Step 9 — Sensitivity and uncertainty.

Sensitivity to arrival rate, service time distribution, and nurse count.
Uncertainty propagation with arrival rate and service time drawn from fitted distributions.

Step 10 — Scenarios.

Factorial design: nurse count (3, 4, 5) × arrival rate (off-peak, peak) × service time (baseline, 20% slower). Twelve treatments, 50 replications each.

Step 11 — Interpretation.

Identify the staffing level that keeps the 90th-percentile wait below 20 minutes under both peak conditions and both service-time assumptions. State the conditions under which the recommendation holds.

Step 12 — Report.

Technical report for the clinic's operations research team; executive summary for the clinic director.

Step 13 — Presentation.

Ten-minute presentation for the clinic leadership. One slide per idea; plain-language charts.

Step 14 — Archive.

Spreadsheet with the model, separated from the analysis outputs.
Data files with anonymised arrival and service records.
Readme documenting the order of operations, the seeds used, and the software version.
All figures and tables from the report.

Iteration anticipated.

The plan anticipates iteration at two points: (i) if verification reveals a discrepancy against the M/M/c formulas, the implementation will be revisited; (ii) if validation fails, the service-time distribution or the arrival model may need revision. Iteration is documented in a project log.

6 Verification check

Checks to perform on your integration

Is every lifecycle step addressed somewhere in the project? Use the fourteen-step list as a checklist.
Are the dependencies respected? For example, the specification must precede the implementation, and the verification must precede the validation.
Is the iteration documented? A project log records what was revisited and why.
Is the reproducibility package complete? Model files, data, seeds, versions, procedure, outputs.
Does the claim-support statement follow from the evidence? The statement should reflect what was actually verified, validated, and tested.
Is the project manageable in the available time? A project that is too ambitious risks being incomplete; a project that is too modest may not demonstrate the required competencies.

7 Interpretation

The capstone project is an exercise in professional modelling practice. The value is not in the finding — many capstone projects confirm what is already suspected — but in the rigour with which the work is done and the clarity with which it is communicated.

Three interpretive points:

The process is the deliverable. A capstone is judged on how well the fourteen steps were executed, not on whether the finding is novel or surprising.
Iteration is expected, not a failure. A project that never iterates is either trivial or was not honestly documented.
Reproducibility is a first-class deliverable. A project that cannot be rerun by another analyst is incomplete, regardless of the quality of the results.

Self-assessment against the rubric

The capstone rubric (available in the course materials) lists the criteria on which the project is assessed: problem definition, formulation, method selection, implementation, verification, validation, sensitivity analysis, results, reproducibility, and communication. Use the rubric as a self-assessment tool throughout the project, not only at the end.

8 Uncertainty and limitations

Every capstone project carries uncertainties that extend beyond the model itself.

Uncertainties in a capstone project
Source	Effect
Scope of data	The model is only as good as the data used to calibrate and validate it
Model-form choice	Choosing DES when an ODE would suffice (or vice versa) limits what the project can say
Time constraints	Limited time may force simplification or reduce the scope of analysis
Stakeholder expectations	The recommendation may not match what a stakeholder hopes to hear

A capstone is not a doctoral thesis

The capstone demonstrates competence in the modelling process, not a novel contribution to knowledge. The scope should be ambitious enough to exercise the full cycle and modest enough to be completed with rigour.

9 Common implementation errors

Watch for these

Skipping steps in the lifecycle. A project that omits validation or reproducibility is incomplete, regardless of how impressive the analysis is.
Undertaking a project that is too large. A project that cannot be completed with rigour is worse than a modest one completed thoroughly.
Leaving the report until the end. Documentation should be written alongside the work; retrospective documentation is usually incomplete.
Not archiving the seeds. Without the seeds, the stochastic results cannot be reproduced.
Writing only for the technical audience. The executive summary and presentation are required deliverables.
Overstating the finding. The recommendation should be conditional on the model's assumptions and consistent with the evidence collected.
Not self-assessing against the rubric. The rubric defines the assessment criteria; not using it as a self-check is a missed opportunity.

10 Independent modelling task

Your turn

Draft a project plan for the capstone, following the fourteen-step lifecycle.
For each step, write one or two sentences describing what you will do and what the deliverable will be.
Identify the three steps that will require the most time and the two that are most likely to trigger iteration.
Produce a one-page timeline: which steps occur in which weeks, and which deliverables are due when.
Draft the table of contents for the technical report. Include a one-sentence description of each section.
Draft the executive summary template (the five questions) with placeholder text for the answers.
List the contents of the reproducibility package for the project.
Self-assess against the capstone rubric, marking each criterion as "on track," "needs work," or "not yet started."

This exercise produces the capstone project plan and is a direct input to the capstone submission.

11 Reflection prompt

Reflect before continuing

Of the fourteen lifecycle steps, which one do you expect to spend the most time on for your capstone, and which one do you expect to find most challenging?

Two or three sentences. Name the steps and briefly explain why. The reflection will help you prioritise your work.

12 Lesson summary

Key takeaways

The capstone exercises the full fourteen-step lifecycle. Every step must appear, and the dependencies must be respected.
Iteration is expected. Later steps frequently send the project back to earlier ones. Document the iterations.
The reproducibility package is a first-class deliverable. Model files, data, seeds, versions, procedure, and outputs.
The process is the deliverable. A capstone is judged on rigour of execution and clarity of communication, not on novelty of the finding.
Self-assess against the rubric throughout. The criteria define what a successful project looks like.

Module 7 and the course complete

You have verified models, validated them, characterised their sensitivity, designed experiments, communicated results to technical and non-technical audiences, and integrated the full modelling cycle into the capstone project. The remaining work is the capstone itself, which draws on every module of the course.

§ Self-quiz, practice, and homework

Practice exercises

For a project of your choice, list the fourteen lifecycle steps and, in one sentence each, state what you would do at each step.
For the same project, identify two steps where iteration is likely to occur, and describe what would trigger the iteration.
List the six components of the reproducibility package. For each, state what would be included for a small project.
Take a rubric criterion (e.g. "verification and numerical testing") and write three sentences describing what a strong submission would look like for that criterion.

Homework problems

Project plan. Produce a full project plan for the capstone, covering all fourteen lifecycle steps. For each step, state the deliverable and the criterion for completion. Include a one-page timeline. 800–1200 words.
Reproducibility package inventory. For your capstone, list every file that will be included in the reproducibility package. For each file, state its purpose and its format. Identify any information that would need to be recorded but is not naturally part of a file (e.g. manual steps, seed policy).
Rubric self-assessment. Take the capstone rubric. For each criterion, write a paragraph assessing your current capstone progress and identifying what remains to be done.

Mini project

Produce a complete capstone project plan and reproducibility package inventory. Include: the fourteen lifecycle steps with deliverables and criteria, a one-page timeline, the technical report outline, the executive summary template, and the reproducibility package inventory. Submit as a single document. This is the final preparation for the capstone submission.