Semester Project
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| Runnable project implementation and repository structure | Portfolio candidate | Polish the public repo only after tests pass, secrets are removed, and setup steps work from a clean checkout. |
| README with setup, inspection, verification instructions, and known limitations | Portfolio candidate | Make this public-facing if the project is safe to share; keep internal coursework notes in a private evidence folder. |
| Tests, traces, proofs, diagrams, benchmark outputs, or review notes required by the brief | Checkpoint evidence | Keep raw logs, benchmark runs, and reviewer comments private by default; publish summarized or reproducible versions when useful. |
| ADRs, design memos, runbooks, benchmark reports, and other high-effort engineering writeups | Portfolio candidate | These are worth polishing publicly when they tell a clear tradeoff story; otherwise keep them as private coursework evidence. |
| Final reflection, retrospective, or carry-forward notes | Checkpoint evidence | Keep candid self-assessment private unless rewritten as a concise public learning note. |
Project title: Algorithm Explorer + CS Map Notebook
info
Build one small but real application that turns Semester 0 into evidence. The project should make one algorithm visible step by step, capture one clear CS-fundamentals explanation, and show that you can separate logic, data, and presentation cleanly.
Problem Statement
Semester 0 is easy to fake. You can read about algorithms, read about computer science, and read about clean code without producing any artifact that proves you can explain, structure, and verify your thinking.
This project fixes that by asking you to build one small tool that combines all three modules:
- It visualizes at least one algorithm from Module 1 so the state changes are visible instead of magical.
- It captures one usable CS explanation from Module 2 so your mental model becomes an artifact instead of a vague summary.
- It is organized with clear components, tests, and data flow so Module 3 stops being theory-only.
You may build this as a small web app, a CLI plus static HTML viewer, or a simple desktop-style local app. Keep the scope tight.
Functional Requirements
- Visualize at least one algorithm step by step. Valid choices include binary search, quicksort partitioning, recursion on a tiny problem, or BFS on a small graph.
- Let the user step forward through algorithm states and see what changed at each step.
- Include one CS fundamentals explainer that covers a simple program or scenario using at least these headings: problem model, strategy, data choice, storage or representation choice, and execution stack.
- Store at least one saved scenario, trace, or explainer artifact between runs using a simple documented storage choice such as JSON, SQLite, or browser local storage.
- Expose the saved artifact back to the user so the project is more than a one-shot demo.
- Include a short architecture note in the README explaining input, logic, storage, and output.
Non-Functional Requirements
- The project must be runnable from the README in 5 minutes or less.
- The codebase must separate domain logic from UI or presentation code.
- The project must stay intentionally small enough to finish in Semester 0. Prefer completeness over ambition.
- Names, file layout, and data shapes must be clear enough that another learner can follow the project without a guided tour.
Cross-Cutting Tracks
- Track A (Testing L1): Write unit tests for at least one algorithm-step helper or state transition and one CS-explainer formatting or validation rule.
- Track B (Git L1): Use small commits and at least two feature branches, such as
feature/algorithm-visualizerandfeature/cs-explainer. - Track E (Engineering Fundamentals L1): Include basic run instructions, input assumptions, and one short debugging note in the README or reflection.
Architecture Expectations
note
Semester 0 rewards clear boundaries over cleverness. Keep the moving parts obvious.
Expectations:
- Keep algorithm-state generation and CS-explainer formatting outside click handlers or display code.
- Document the stored data shape for traces, saved scenarios, or explainer notes.
- Make the algorithm visualizer expose intermediate states, not only the final answer.
- Leave one obvious extension point for a second algorithm or second explainer later, even if you do not build it now.
Suggested Milestones
| Milestone | Deliverable | Notes |
|---|---|---|
| 1 | One algorithm visualizer can persist and reload a trace | Start with plain data and tests before polish |
| 2 | One CS explainer artifact is viewable in the app | Keep the scope to one well-explained scenario |
| 3 | The visualizer and explainer share a clear project structure | Prefer one clean architecture over extra features |
| 4 | README, reflection, and Git cleanup | Make the project runnable and explainable |
Optional Python Repair Extension
If your Python fundamentals are still shaky, add a small Wordle-style guessing lane before final submission. Keep it deliberately modest: a fixed answer, a six-guess limit, and feedback for exact matches, present letters, and missing letters.
Implementation requirements:
- Model the game state with plain data first: answer, guesses, remaining attempts, and status.
- Use variables, conditionals, loops, functions, lists, dictionaries or sets, modules, and file I/O at least once in meaningful places.
- Put scoring and validation in testable functions, not in the input loop or UI.
- Add tests for repeated letters, invalid guesses, win/loss transitions, and persisted game history.
- Connect the extension back to the CS explainer by tracing one guess through input, validation, state update, feedback generation, storage, and display.
Evidence check: include one screenshot or terminal transcript, one state-transition test file, and a short note explaining why a set, dictionary, or list was the right data shape for at least one part of the game.
Deliverables Checklist
- Repository or folder with a README covering problem, setup, run steps, and project structure
- Working algorithm visualizer with labeled steps or states
- Working CS fundamentals explainer that meets the functional requirements above
- Tests for non-trivial logic
- Git history that shows focused commits and branch-based work
- Short reflection of about half to one page covering what was hard, what you would improve next, and which Semester 0 concept most changed the way you built the project
Grading Rubric
| Criterion | Weight | Excellent | Acceptable | Needs work |
|---|---|---|---|---|
| Meets requirements | 25% | Visualizer, explainer, persistence, and README all work cleanly | Most core requirements work with small gaps | Major features missing or unclear |
| Code clarity and structure | 20% | Clear boundaries, naming, and readable file layout | Mostly understandable with minor mixing of concerns | Logic and UI are tangled or hard to follow |
| Algorithm visualization quality | 20% | State changes are obvious and well explained | Algorithm works but step visibility is limited | Final answer appears with little explanation |
| CS explanation quality | 10% | The scenario is modeled clearly across strategy, data, storage, and stack layers | The scenario is understandable but shallow in one area | The explanation is vague or disconnected |
| Testing | 15% | Core calculations and step logic are covered by meaningful tests | Some tests exist but coverage is narrow | Tests are missing or superficial |
| Git practice | 5% | Small, readable commits and clean branch-based progress | Some good history, but inconsistent | Large dumps or unclear commit history |
| README and reflection | 5% | Another learner can run, understand, and evaluate the project quickly | Documentation exists but leaves some gaps | Hard to run or hard to understand |
Production-Style Project Brief
Use this project as a reviewable engineering brief, not only a completion exercise.
Problem statement
Write a one-paragraph statement covering the user, the problem, the constraint, and the outcome this project is meant to produce.
Required evidence
- working artifact or reproducible deliverable
- README with setup, inspection, and verification instructions
- tests, traces, proofs, diagrams, benchmark output, or review notes appropriate to the semester
- decision log with at least three meaningful tradeoffs
- known limitations section with explicit scope cuts
Review questions
- What is the smallest vertical slice that proves the project works?
- Which requirement is most likely to be misunderstood by a reviewer?
- What did you deliberately not build, and why?
- What evidence would convince someone else that the result is correct?
Done means
The project is done only when another technical reader can inspect the artifact, run or review the verification evidence, and understand the tradeoffs without a live explanation.
Weekly Project Milestones
Use these milestones to keep the project from becoming a last-week scramble.
| Milestone | Focus | Evidence |
|---|---|---|
| Start | Scope the smallest useful slice | problem statement, non-goals, first task list |
| Early build | Produce a walking version | runnable skeleton, first test, first committed artifact |
| Middle | Add the hard part | implementation note, trace/proof/benchmark/design decision |
| Review | Stress the weak point | failure case, debugging note, peer/self review, correction commit |
| Finish | Package for inspection | README, verification instructions, known limitations, reflection |
Answer-Quality Examples
| Quality | What it sounds like |
|---|---|
| Weak | "I built it because the module asked for it." |
| Acceptable | "It works for the required examples and I can explain the main idea." |
| Strong | "Here is the tradeoff I chose, the evidence that supports it, and the case where it would fail." |
| Portfolio-ready | "A reviewer can inspect the artifact, rerun the checks, and understand why this solution fits this semester's goals." |
Future Capstone Connection
Before closing this project, write two sentences on how it could help the final capstone: one reusable technical skill and one artifact habit to preserve.
Calibration Materials
Use these learner-visible calibration materials before self-grading or requesting review: