Student Organizer Assignment — Simple Team Guide
This is a plain-language walkthrough of what the assignment actually wants, before you dive into the detailed worksheet. Read this
together as a team first.
1. What are we actually building?
A small C++ program that stores a list of students (ID, name, grades) and lets you add, change, remove, find, and show
them — instead of keeping that info in spreadsheets.
2. The 7 concepts, explained simply
Your assignment keeps mentioning these terms. Here's what each one means and where it shows up in your project:
Data vs. Information
Plain English: Data is raw facts (e.g. '87'). Information is data with meaning (e.g. 'Sam scored 87 in Math').
In this project: Your student records turn raw numbers into meaningful info.
Data type
Plain English: The kind of value a piece of data is — a whole number, decimal, text, etc.
In this project: Student ID = integer, name = string/text, grade = decimal (float).
Data structure
Plain English: A way of organizing many pieces of data together so you can use them efficiently.
In this project: Arrays are your data structure — they hold many students or many grades.
One-dimensional (1D) array
Plain English: A single list of items in a row.
In this project: A simple list of student IDs or student records, one after another.
Multidimensional array
Plain English: A grid — like rows and columns (e.g. a spreadsheet).
In this project: A grid of grades: one row per student, one column per subject/semester.
Abstraction
Plain English: Hiding the complicated details and only showing what's needed.
In this project: Someone using your program just calls 'searchStudent(id)' — they don't need to know how the search works inside.
Encapsulation
Plain English: Keeping a class's data private and only allowing changes through specific methods.
In this project: The student's data fields are private; you can only read/change them through getter and setter functions.
Abstract Data Type (ADT)
Plain English: A custom "container" concept that bundles data with the operations allowed on it, hiding how it works internally.
In this project: Your StudentOrganizer class is the ADT — it offers insert/update/delete/search/retrieve/display without exposing
the raw arrays.
Operational / Tactical / Strategic decisions
Plain English: Operational = daily tasks. Tactical = short/medium-term department decisions. Strategic = big-picture, long-term
planning.
In this project: Operational: looking up one student's grade today. Tactical: flagging students at risk this term. Strategic: changing
the curriculum based on years of failure trends.
3. What you need to hand in (plain version)
What to hand in
In plain words, what this is
Problem analysis (max 2 pages)
A short write-up explaining the school's
problem and why data structures fix it.
Design diagram
A picture/drawing showing how the data
is organized (arrays, the ADT box, etc.).
C++ program
The actual working code.
Test data & results
Proof you tried the program with different
inputs and it worked (or you fixed it).
AI reflection (short)
A few sentences on how AI helped or
didn't. Separate from the log below.
AI Use & Verification Log
A table showing every time you used AI,
what you asked, and what you kept or
fixed.
5-minute demo
A short live or recorded walkthrough of
the program.
Who's doing it
Done?
4. Rough team split (adjust freely)
You don't need exactly 4 people or these exact titles — merge or split based on your real team size.
Who
What they focus on (plain terms)
Name
Person A — Code Builder
Writes the actual C++ program: the Student info holder
and the main program that
inserts/updates/deletes/searches/shows students.
Person B — Data Organizer
Decides how the lists and grids of data are stored (arrays),
and can explain why.
Person C —
Writer/Explainer
Writes the problem analysis, draws the diagram, and
explains it in plain words.
Person D —
Checker/Recorder
Tests the program, keeps the AI log, and puts together the
demo.
5. Using AI — what's allowed and what to record
You CAN use AI to brainstorm, explain concepts, write a first draft of code, find bugs, suggest test cases, or clean up
your writing.
You must NOT just copy AI's code without understanding or checking it — that loses marks.
Every time you use AI in a way that ends up in your project, jot it down here:
AI tool
What we asked it
What it gave us
Kept it or fixed
it?
How we checked it
was right
AI tool
What we asked it
What it gave us
Kept it or fixed
it?
6. Simple order to do things in
• Step 1 — Understand: read this guide together, agree on who does what.
• Step 2 — Plan: write the problem analysis and draw the diagram before coding.
• Step 3 — Build: write the C++ code (Student class, then StudentOrganizer, then the 6 operations).
• Step 4 — Test: try normal inputs, then weird/edge inputs (empty list, full list, wrong ID).
• Step 5 — Log & reflect: fill in the AI log and write the short reflection.
• Step 6 — Rehearse: practice the 5-minute demo so it fits the time and everyone has a part.
7. Quick self-check before submitting
• Can we explain, in our own words, the difference between data, a data type, and a data structure?
• Does the code actually compile and run?
• Did we test at least one case where something could go wrong (full array, missing ID)?
• Is there at least one AI log entry where we caught and fixed a mistake?
• Does everyone on the team know what they're presenting in the demo?
How we checked it
was right