WH-FINAL - Management Report and Reproducible Code

You are free to use any tools or programming language, as long as the evidence used in your report is generated automatically by code and saved in a folder. This includes numerical results, KPIs, data tables, the data behind charts, and the charts themselves.

You can submit a project folder and use GitHub to collaborate. The warehouse project template includes Python and notebook examples that run the same analysis and save the same evidence. Adapt an example or use your own tools.

Management Report

Provide one management report of no more than 12 pages as a PDF, together with its complete LaTeX project, bibliography, and generated tables and figures. The report brings together the findings from AS1 through AS5 in one management argument. The warehouse project template contains an example report and guidance for each section. You can use its structure or organize the report to suit your management argument. Choose your own subsections.

Introduce the warehouse problem and the decisions being evaluated. Explain the data and methods, then present the activity profiling, storage, layout, and picking results. Bring the results together in the performance comparison and conclude with your recommendation and its limitations.

Summarize the intervention comparison in one table with scenario definitions, feasibility status, resource requirements, performance measures, and changes from the current situation.

Keep each reported result traceable to the analysis code and saved outputs. Give units in table headings and chart axes, and explain the finding in each caption. The template’s example values and figures must be replaced with your own analysis.

The syllabus gives the five report-part rubrics and the assessment conditions. Each student must be able to explain the complete submitted report and code during the individual oral defense.

Run the Analysis With One Command

Put the original files downloaded from the approved course sources in data/raw/. Provide one entry point that runs the analysis from the project root and saves the evidence used in your report.

Keep the README brief. Give the setup, the command to run, and the output folder. For example:

To generate the evidence, run python generate_artifacts.py from the project folder. The code reads the original files in data/raw/ and saves the outputs in artifacts/.

Use the command appropriate for your language and tools. It should run the analyses behind the report and save their outputs automatically. For a notebook, the entry point executes its cells from start to finish. Record scenario settings and random seeds in your code so the analysis can be repeated.

For scenario-based analyses, define the retained options in the code and generate their combinations automatically. Give each scenario a stable identifier. Use the same scenario names in the report, code, and saved outputs. For each scenario, save its definition, assumptions, settings, feasibility status, and results. Record solver status where applicable.

The supplied template checks existing input files and downloads missing ones. The Turing Way gives further guidance on packaging a reproducible project.

Choose an Entry Point

The following examples illustrate ways to meet the requirement. The template README gives their setup and execution commands.

Example	Delivery	Main trade-off
1	Python scripts with a dependency file and a documented command	Straightforward to run and inspect; requires a Python environment with the specified packages.
2	A notebook with dependencies and a command that executes it from start to finish	Keeps explanation beside analysis; execution starts with a fresh kernel and saves outputs as files.

Organize the Files

Keep the originals in data/raw/ and arrange the remaining files to suit your tools. Here is one example:

warehouse-project/
├── README.md                 # setup, commands, expected outputs
├── run.cmd                   # example command
├── environment.yml           # or another dependency file
├── data/
│   ├── raw/                  # downloaded originals; includes .gitkeep
│   └── processed/            # derived data
├── src/                      # reusable code
├── notebooks/                # notebooks
├── report/
│   ├── main.tex              # report source
│   ├── references.bib
│   └── figures/              # generated figures, copied or imported
└── artifacts/                # generated evidence

Import or copy the generated evidence into your LaTeX report. You may start with an IEEE conference LaTeX template. Cookiecutter Data Science gives another example of how to organize project files.

Submit the code and complete LaTeX project as a ZIP or a link to the exact Git commit you want assessed. Include the generated assets and brief compilation instructions, and submit the final PDF through Canvas. The existing assessment criteria and separate WH-AS1 formative notebook and peer-review requirements continue to apply.

The SPR project page says the company data are copyrighted and proprietary and limits their use to course purposes. Do not put the raw files in a public repository. Check generated files before sharing them so they do not reveal source records. If you use Git, these rules keep the empty folder while ignoring its contents:

data/raw/*
!data/raw/.gitkeep

Document and Check the Run

The documented analysis must run in a clean folder and produce saved outputs that agree with the PDF.

Include the dependencies needed to run your command and identify the source files used by your analysis. Keep original files unchanged and save generated evidence in a separate folder. Use consistent names so readers can find the evidence behind each reported result, table, and chart.

Before submitting:

Clone the exact commit or unpack the ZIP in a clean directory and install the documented prerequisites.
Put the original inputs in data/raw/ or let your code obtain them. Run your documented command and check that it saves the evidence used in the report.
Compare the saved outputs with the submitted report, including rounded values and the data behind each chart. Replace any copied assets that are out of date.
Follow your separate LaTeX instructions to compile the submitted project and check the final PDF.

Quick Reproducibility Check

For a lengthy analysis, consider providing a documented quick test that reviewers can complete within about 15 minutes, including setup. State which results the test checks and what remains untested.

Report and Code Quality

The teaching team may deduct up to 5 points from the 50-point coursework total for report and code quality. The column percentages in Table 26.1 apply to the maximum deduction shown beside each criterion. AS1 through AS5 retain their existing scores.

Table 26.1: Report and code quality rubric.

Criterion (maximum deduction)	Meets requirements (0%)	Needs correction (50%)	Substantial problem (100%)
Analysis execution (2 points)	One documented entry point runs from the original inputs in a clean folder and saves the required outputs. Setup, dependencies, scenario settings, and applicable seeds are recorded.	A documented setup or execution fix is needed, or some outputs require manual steps.	Missing code, dependencies, or inputs, or execution failures, prevent generation of the required outputs.
Outputs and PDF (1 point)	The PDF matches the submitted outputs and uses consistent scenario definitions and names.	A limited version or naming mismatch affects the evidence, but the intended result can be established.	Material mismatches prevent a reliable comparison of the outputs with the PDF.
Report sources (1 point)	The supplied LaTeX sources, bibliography, assets, and instructions reproduce the submitted PDF.	Compilation requires a documented correction to the instructions or a missing asset.	Missing sources or material assets, or compilation failures, prevent reproduction of the PDF.
Readability and navigation (1 point)	Structure, formatting, terminology, and cross-references make the evidence easy to locate and inspect.	Recurring presentation or navigation problems hinder inspection of some evidence.	Substantial presentation or navigation problems hinder inspection of the report’s evidence.

Each underlying defect is assessed once, in its applicable criterion. An incorrect model or calculation is assessed under AS1 through AS5; an execution or packaging defect is assessed here. Model validity, data provenance, technical figure accuracy, uncertainty, and the management recommendation remain within the assignment rubrics. Language fluency or presentation style alone does not justify a deduction.

A single defect that affects several outputs or assignment parts receives one deduction. For example, a broken file path is an execution defect, while an incorrect picking calculation belongs under AS4. The teaching team assesses analytical evidence that remains verifiable and records any claims that cannot be substantiated. It does not apply a blanket reduction across AS1 through AS5 for a packaging defect or deduct again for that same defect. Separate deficiencies require separate evidence.

The teaching team verifies deductions against the package being assessed and records the affected criterion, supporting evidence, and points deducted. A reviewer’s unavailable software or access, or a check recorded as “not checked”, does not establish a defect in the submitted package.