If the result of your work or research is a software system, a demo may be required to explain to others how your system works, why it's interesting, and why it's worth researching. Demos can be rigidly scripted, where only the presenter uses the software and others watch the interaction, or they can be less formal where anyone who wants to can use the system. These different types of demos require some different preparation.
 General demo advice
 Know the software
You are demonstrating how the software you created works. You should feel quite comfortable using the software, and should be able to use it both slowly (to explain how the software works) and efficiently (to demonstrate how quickly it works).
 Save working programs
You want your demo to be successful. It is a very good idea to keep backup copies of the executables for your demos, instead of relying on the cutting-edge code in your version control system working. If you rely on external data, it could be a good idea to save a working copy of this data. You don't want to need to delay your demo while waiting for a bugfix to compile.
 Scripted demo advice
 Have a detailed plan
You want to avoid improvising, since you might forget to mention something important, or may discuss important concepts out of order. You should know what you will be demonstrating in what order. Some people  encourage you to have a clear story for your demo, and to use that story to motivate the demonstrated features.
 Practice, practice, practice
Demos have more ways to go wrong than talks, so you should arguably practice them even more thoroughly than a talk. You should feel comfortable using the software, and you should be able to answer reasonable questions. Additionally, you should try to answer common questions before they are asked. If in your practice talks, the audiences frequently ask the same questions, see if there is a way to clarify that point without the question being asked.
 Streamline as much as possible
You want the focus of the demo to be your impressive software. For example, if you need to open files from inside your program, place them all in one location where they can be easily found.
 Interactive demo advice
 Handle invalid input
When you're letting others use your software, your software should be essentially uncrashable. You might know how your software wants input to behave, but you should assume the user will not abide by these requirements.
 Know how to reset
If your software has various modes in it, you should assume that the user could accidentally enable one of these modes and get stuck. You should be able to quickly identify this and switch the software back to a working mode.
Even if your software doesn't have modes, it's entirely possible that it could somehow get into a corrupted state and need to be restarted. You should know how to re-launch your program as quickly and easily as possible.
 Practice explaining your software
When a new user is introduced to your software system, you should know how to explain the system to them. If multiple people are involved in presenting the demo, they should each know and agree who does the majority of the talking. If multiple people are trying to explain software at the same time, it can confuse the user and create a worse impression of your system.
 Be ready to talk
Know how the program works, so when the users ask questions, you are able to answer intelligently. If you are unable to answer a question, it is far better to admit it than to try to stumble your way through an answer.