How to defend your final year project software

What a panel checks

• The design: who uses the system, what each person can do, the database tables and how they connect.
• The working system: it starts, it does what Chapter 3 says, and it handles a wrong input sensibly.
• You: whether you understand what you are showing.

The third one decides most defences. A simple system you can explain beats a large one you cannot.

Questions you should expect

• Why did you choose this language and this database?
• How are passwords stored? (They are hashed, never saved as plain text.)
• What stops a member of staff from opening an admin page?
• Show me the table that stores this record. What is its primary key?
• What happens if I leave this field empty?
• How did you test the system?
• What are its limitations, and what would you add next?

Your project comes with twenty questions like these, answered from your own code, naming the real files and functions.

A preparation plan

1. Run the system yourself and use every screen as every kind of user.
2. Read the guide once from start to finish. Then read the three walk-throughs again with the code open beside them.
3. Do the three "change it yourself" exercises. Changing the code is the fastest way to understand it.
4. Replace the sample data with a few records of your own, and change the school name to yours.
5. Say the defence answers aloud, in your own words. Do not memorise them.
6. Practise the demonstration from a cold start: laptop off, then running in under two minutes.

Be honest about how it was built

If you are asked whether you used AI, say yes, and then show that you understand the result. Every project includes a short statement on this. Panels respond far better to honesty with understanding than to a claim that falls apart at the first question.