The first challenge roots in the ToDo manager designed by us, because it is us who decided which inputs are valid or invalid. In all, there are two scenarios of this challenge. One scenario is that some time expressions cannot be distinguished by the software. Although the third party library introduced can identify a lot of time expressions, it cannot distinguish all the situations; for example: “forty-five days later” is regarded as “five days later” by mistake. The other scenario is that the test cases including script testing and exploratory testing we used may not cover all the situations where a bug occurs or an exception is thrown. It is possible that the person who tests our software types some inputs, resulting in a bug or an exception, because all the classmates have tested their software a lot and they know which test case is more prone to find errors.
To solve the first scenario, there are two suggestions. One suggestion is to clearly state the restrictions before someone tries out the software. The demonstrator should tell the user which kind of inputs is invalid. However, this method just avoids problems occurring during the presentation, but not solves the problem for the users. While the other suggestion can solve the problem permanently, which is removing more restrictions and making the software distinguish more time expressions. For the second scenario, the suggestion is to get the help of coverage tools introduced in the last CS2103T lecture to tell us how much percent of the codes we have tested. In this way, more errors or exceptions can be avoided.
The first challenge is more about the software, while the second one focuses more on the presentation skills, which is how to make the presentation professional. In my opinion, this presentation should be taken as one for real business, because the aim of this module is to make us ready for real business. Thus, the demonstrators should make their best to be professional. However, to show professionalism is not easy for me, and I still have to practice a lot in the future to achieve that.
One technique of appearing to be professional is to show passions and interests towards the product, and the passions and interests of the demonstrator will influence the audience positively. In addition, another technique is that the demonstrator should make the audience more willing to accept or at least remember the software. How to achieve this? One way is make a distinction between the primary and secondary features; for example, the demonstrator of Schedulicity emphasized the most important feature of their product by saying “the most exciting part is…”. I found this technique is quite useful to catch my attention and as a result, I thought that demonstrator was quite professional.
The two challenges above are faced by me now, and the focus of the preparation is mainly on how to solve these two potential problems.
Actually, I think honesty is very important in a software demo. For me, I would most likely choose the first solution, which is to reveal the constraints of the inputs before allowing the audiences to try on the software. This way, the audiences know what to be expected and would still trust the capabilities of your software. But as you have mentioned, this does not fix the real problem itself. It is always better to improve the software to the level that it does not have any constraint at all. But such would require a considerable amount of time. So if times are limited, then using the first solution would be the only option. For our project, since we still have time, it is better for us to improve our software even better before the deadline.
回复删除Actually, the demo is not easy to do. We should try to show the advantages and hide the weaknesses. We knows that our software is not perfect and there might be some problem occurs during the demo. Of course, we should consider the second solution first. Try to make the software as smooth as we can. But the time is limited, we only have four days and we also need to spend some time on preparing our slides and speech. So if we are still sure whether there are any bugs in our software on the deadline, we had better tell the listeners the truth that our software may not work on some use cases.
回复删除Wish us all the best for OP3.
In my opinion, I also agree that the software demo is not easy to perform. Although we should try our best in order to show and to emphasize on the advantages of our product, being honest is much more important. Therefore, we should let the users know all the limitations such as requirements of inputs before let them try using our software on the spot. By doing this way, the audiences will know what to be expected after all. Moreover, the audiences will only be impressed by what we can do rather than what we hope to do. Hence, telling the truth in this circumstance is not that bad. However, the real problem is still there. The only solution for this problem is to improve the software to be able to work under all types of users’ inputs. Because of time constraint, we cannot satisfy that ambitious goal and the first solution seems to be the only available option. However, since we still have one more week, we will try our best to improve our software as much as possible.
回复删除