Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Demo Tips - Mike Hirth
"Presentation is everything." - somebody
You will be putting in a lot of long nights and hard, finger-breaking work into this project which your grader is not going to see. Instead, he or she will see exactly what you show him or her when you demo each milestone of your project. So get sharp and take the following tips:
- Don't panic. TAs are your friends and they want you to succeed as much as you do.
- Have a gameplan. Usually groups spend a lot of time getting everything to work right up to the demo and then are too focused on the details to give a good presentation. Try and leave some time to plan for a successful demo.
- This could translate to taking a look at every requirement and coming up with an example test and then actually practicing it.
- Know your bugs.
- It's smart to try entering different kinds of input data into your application during the development process to test it. It's even smarter to remember a set of practice input data when it comes time to demo. If you enter in random data at demo time, despite your confidence you may run into some errors.
- For instance, I had tested a form by entering non-zero numbers but when we had our demo I entered in a zero and it caused issues.
- Be confident. Don't get let down by mistakes or errors. There are often things that you will catch that your grader will not.
- If the TA asks a question that you can't answer, look to your partners. Partners: jump in if someone is struggling! You probably all worked on separate parts and will all need to demo or explain something.
- Some milestones are easier to do with multiple computers. Assign different group members to demo different criteria and the demo will fly by.
- Sometimes it is good to keep different versions of the application on different members' computers (once you start with version control). This is especially important once you start throwing the GUI over your project, since it is likely you still have to test some domain functionality.
- Have prewritten workspace code that demonstrates all necessary functionality and keep it. If your GUI isn't working correctly and if your S-Unit tests aren't working, this can really save you. I spent the majority of one demo writing workspace code and you don't want to be there.
- Communicate with the grader. Chances are they have certain things they want to see and they need to get to all the groups, so don't get carried away explaining how super-fly your design is. Making eye contact and conciseness helps.
- Version control can get messy. You will probably see at least one group freaking out before a demo because someone committed and destroyed their beautifully functional code. Avoid this by making a 'final commit' the night before and rerunning tests/re-testing inputs every step. Also, you can always go back a version if merging causes failures. That's what they made it for. see the version control cases
- Get sleep, speak slow, drink water. The usual stuff.
Keep some of these in mind and you will do a supreme job. One more thing: when you start to stress, take a deep breath. It helps.
Image from thefuntimesguide.com
Links to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu
- Most Helpful Cases last edited on 11 December 2010 at 4:57 pm by res-128-61-90-36.res.gatech.edu