OP3, which is the final oral presentation for C1 module, is actually a software demo of our product software in CT module. I have no prior in doing software demo, but I have witnessed a few real software demos on stage. Although it is entirely another level for us, but I think it is good to learn from examples.
I am in charge of the introduction part of OP3. Therefore, I have been watching a few videos of software demos from YouTube. I find that there are actually many ways of introducing software before doing the exact demo. Some started with playing an attractive short video, some started with a story, some started with a joke, and other ways. There so many of them that I find it hard to select one and use it on OP3. But it is a good learning experience to see so many interesting introductions, and I may be able to have a style of my own in the future.
One aspect of software demo that I find it to be controversial is the person who does the demo. Should it be the developer of the software? Or is it more appropriate to let the audience to try the software on the spot? From what I have seen on YouTube, all the software demos done on stage are handled by the developers of the software. This is clearly better in the sense that the audience would know how to use the software at first glance, while the developers know how to test it on the spot. However, this is done in pre-assumptions that how they do it on stage will be exactly how it works when the audiences use the software. It is possible to turn out to be entirely different when the users use the software. Therefore, it is arguable that they should let the audiences to try the software during the demo.
For OP3, my group has not decided whether we should do the demo ourselves or let the audiences try the software. However, for me, if I have another software demo to be done in the future, I would try my best to give chances for the audiences to try the software on the spot. This way, not only the audiences will be convinced by the demo, they can have a better understanding on the software’s behavior as well. However, there will some risks where the audiences would screw up the software demo. I cannot say for sure how exactly it may happen, but there is such possibility. But it is my job to reduce these risks by making the software as bulletproof as possible. This would require the knowledge I learned from CT module.
In a nutshell, software demo is an essential stage that every software engineer will have to go through in their project. Therefore, it is crucial for us to apply what we have learned in C1 module to make the demo as smooth as possible, and ultimately, to persuade the audiences to use our product software.
Previously, I also found it extremely difficult for me to decide if one user will be allowed to try out our software during the demonstration. After thinking it over and over again, I determined to let one user try the software. This is because it will increase the credibility of the software. If only the demonstrator shows the audience how to use the software, the audience may doubt whether the software can work well under other input cases, but not only the test cases used by the demonstrator. On the contrary, the audience may think “Well, the software really works well as what the demonstrator has just said” if he or she is involved in the demo. Therefore, I prefer to let the audience have the chance to try out the software.
ReplyDeleteIf we let the listeners try our PriSec, the command bar can be the most risky part, because our parser is designed based on that the user always type in correct input. It is very possible that our PriSec cannot work well when a listener try to add a new task. Although the risk is significant, I think we should try, because it is a effective to draw attention from the audience.
ReplyDeleteDon't worry too much about this. We have put so much effort on our PriSec, so trust it. It has its unique brilliant points.
All the best for OP3!
As mentioned in my blog, the controller class, which parses users’ inputs, is possibly the weakest component in our system since it is exposed to all variations of inputs. It is possible that some users’ inputs are not recognized and worked as expected. Although there are possibilities that our software may not function properly, it is better to let the user try out our software on the spot during the demonstration session. Direct interaction with the product will give the audiences a critical view of how our software works and what functionalities to expect. It is also better to get the audiences’ hands dirty as users’ attention will be attracted better. Since we only demo our software using some well-prepared scripts, users may not believe that our software can work well under all circumstances (within the requirements). Therefore, letting the users try our software after full explanations of the constraints can clear all users’ doubts and convince them to use our software more easily.
ReplyDelete