Read the article
Start with the problem. One or two sentences: who has it, what they do today, and why that is not good enough. 'Small shops in our town keep stock in notebooks, so they often find out something has run out when a customer asks for it.' That tells the interviewer what the project is for before they hear a single tool name. If your project came from a list the department gave, say so, and then say what interested you in it.
Then say what you built, in everyday words. The idea in one sentence, and the main parts in a few more. After that, name the one or two technologies that mattered and why you chose them. Do not list every library. A long list invites the interviewer to pick one and test you on it, and it is rarely the one you know best.
Next, say which part was yours. Most final-year projects are team projects, and the interviewer knows it. 'I built the stock-alert module and the database design. My teammate did the mobile screens.' This is specific and can be checked. 'We built it' and 'I did everything' are both weaker. If your part was small, say what it was without apology and show that you understood the whole project.
Be honest about the state of it. Say what works from start to finish, what works only on the demo data, and what is not done. Interviewers are not looking for a perfect project. They are looking for someone who knows exactly where theirs stands. A student who says 'the alerts work, but I have not tested it with more than fifty items' sounds far more reliable than one who says it is complete.
Talk about help openly. You may have used a tutorial, a senior's advice, open-source code, a guide's suggestion or an online tool. Say so in a sentence, and say what you changed or checked. 'I started from the documentation example and changed it to handle our data.' The next question will then be about your changes, which is where you want to be.
End on something you can discuss at length: a decision you made, a bug that took a long time, or something you learned. Stop at about two minutes. The aim of the first answer is to give the interviewer something good to ask about.
Now prepare for what follows, because the follow-up is where interviews are decided. Interviewers ask why you chose this database or language and what else you considered. They ask you to walk through what happens when a user does the main thing. They ask what breaks with bad input or many users, how you tested it, and what the hardest bug was. They ask what you would do with three more months. All of these follow from your own answer, so the best preparation is to write your two minutes down, read it as an interviewer, and list the questions it raises.
Finally, practise it aloud, with someone who is not on your team. A teammate will fill in the gaps without noticing. A friend, a senior, or a person who works in the field will stop you at the place where it stopped making sense. That is the sentence to fix.