CSE 491 — Senior Design Project I

Akdeniz University · Computer Engineering (English) · Semester 7

A week-by-week plan for getting a senior design project done, built from the official syllabus. Fifteen weeks, each with concrete deliverables.

Project I ends with a working prototype, not a finished product. Project II completes it.

Grading

Component	Count	Weight
Assignment / seminar	1	40%
Final	1	60%

The plan

#	Week	Deliverable	Note
1	Course introduction	Every deadline written down	weeks/01
2	Project ideas	Three candidate problems	weeks/02
3	Scope and success criteria	Aim, scope, users, measurable criteria	weeks/03
4	Literature review	Comparison of five similar systems	weeks/04
5	Requirements analysis	10 functional, 5 non-functional	weeks/05
6	System design	Architecture, ER diagram, wireframes	weeks/06
7	Technology selection	Decision table with reasons	weeks/07
8	Interim report	Report + presentation + work plan	weeks/08
9	Repository setup	Running skeleton, CI green	weeks/09
10	Core components	Data layer, API, tests	weeks/10
11	User interface	Main workflows clickable	weeks/11
12	Integration	First working version, deployed	weeks/12
13	Testing	Tested against the week-3 criteria	weeks/13
14	Documentation	Final report, repo, README, technical docs	weeks/14
15	Demo	Prototype presentation, Project II plan	weeks/15

How to use this repository

1. Week 3 decides the grade. Write measurable success criteria — 'response under 200 ms', not 'fast'. Week 13 tests against exactly those, and the final report is graded on whether you met them. Vague criteria in week 3 mean nothing to show in week 15.

2. Keep the out-of-scope list. Writing down what the project is not doing is what stops it from growing until it cannot be finished.

3. Set up the repository in week 9, not week 14. The GitHub repository, the README and the technical documentation are graded deliverables. A clean history built over six weeks looks nothing like one assembled the night before.

4. Tick the deliverables in each week file as you go, and record advisor meetings in your own ## Notes — <Name> (<term>) section at the bottom.

5. Test the README on a clean machine. Someone must be able to clone and run your project from it alone.

Layout

README.md        This page
course-info.md   Glossary (Turkish ↔ English)
weeks/NN-*.md    One file per week: the shared plan on top, everyone's notes below
exams/           Past papers (none collected yet) and how to add one
resources/       The official syllabus PDF

Put the project itself in its own repository — this one is for planning, documentation and notes.

Taking notes

Open the week, scroll to the bottom, write under your own heading:

## Notes — <Name> (<term>)
### Lecture
### Worked out by hand
### Questions
### Exam-worthy

Add your heading below the existing ones and never edit someone else's section — different sections merge in git without conflicts. Your section is yours. The shared plan at the top of the file is not — if the course changed, fix it there so the next person gets the corrected version.

Who changes what

What	Who edits it	When
Top of weeks/NN-*.md (goals, key concepts, deliverables)	anyone	Only when the course itself changes — a new topic, a better reading, a correction. Never for personal notes.
## Notes — <you> in a week file	only you	Every week. This is your notebook.
course-info.md, exams/README.md	anyone	When you learn something durable: a new exam pattern, a better source.
assignments/<term>-<you>/	only you	Your assignments, reports, submissions. Use a lowercase, hyphenated name — 2026-2027-fall-efe-kurucay, not Efe Kuruçay. Material whose author is not known goes in assignments/<term>-unattributed/.
resources/<term>/	anyone in that term	Slides, syllabus and lab sheets the instructor issued — the same for everyone taking the course that term.
exams/	anyone	When you get hold of a new paper — blank or answered. Exam papers never go under assignments/.

Two students in different years never touch the same file except to improve the shared plan — which is the point. Several students in the same term work side by side without ever touching the same file.

Terms

What a real project's scope, timeline and outcome actually looked like is the most useful thing a future student can read. When you take the course, add a row naming the instructor, the advisor, the team and the project, and link the project's own repository from it. Future students benefit most from seeing what a real project's scope and timeline actually looked like.

Term	Instructor	Schedule	Midterm	Final	Advisor / team / project	Notes
Fall 2026-2027	TBD — fill in during week 1	TBD	TBD	TBD	TBD	Efe — in every week file