Powdering and polishing the software while preparing for the software demo is the penultimate lap in this ‘race’ to the end of this semester, with the actual delivery of the demo being the final one. It is true that we are facing the heat but this is where our personal and team skills come into play.
Our product is evolving by the day as a result of continual modifications in structure and functionality that we are incorporating to the beta version (V0.1). This became a point of concern when we wanted to finalize the version that we were going to use for the demo. A lot depended on this decision as speakers needed to equip themselves to handle operations concerning the functionality that they are focusing on. This problem was eventually solved as we decided that we will use that version last updated three days before the demo.
There was also this debate on the usage of a video during our demo. I personally felt that using a video was not a good idea as it lacked the throw and feel of a live presentation. Eventually we decided against using a video, thanks to the open-minded approach of my teammates. Our commitments, both academic and non-academic, continue to limit the time we spend on our preparations for the demo. This is something we must live with but perhaps more efficient time management can make life a lot easier.
Once again division of responsibility proved to be a big headache. The evident solution was that each of us present the part that we had developed as we would be most comfortable with that. All of us agreed to this albeit some minor changes. Coming up with a relevant story board, with equal emphasis on the different sections, for the presentation was also challenging. We were and still are discussing means by which we could add that additional bit of excitement and buzz to the demo. We have zeroed in on a few ideas but I do not want to spoil the surprise here!
From a technical point of view, the biggest problem that we are combating currently is the number of bugs in our program. The number of different scenarios that needs to be considered, while allowing users to type in commands, is quite large and this makes bugs inevitable. By bugs I refer to semantic and logical errors rather than syntactical errors. This is something which can be solved by testing the product extensively. At this point I would definitely like to acknowledge the contribution of my teammates in this testing process. A single person can never do justice to testing as his view is bound to be biased in some way. All of us have done extensive testing individually to ensure that the product is bug-free.
The spirit with which we are currently functioning is enough evidence that we are up to the challenge. If we continue to work like this and perhaps add that additional push, I am quite confident that we can pull this off successfully.
Lakshminarasimhan
To decide whether we are going to use a video for the software demo, was probably the most challenging problem in terms of dealing with interpersonal relationship. I agree that the use of a video in place of a live demo would not be a wise decision here, but at the same time we got to recognize the good points of using a video. I like the way the team settle this problem without damaging any interpersonal relationship we have with each other. The open-mindedness of each member as you mentioned is probably the strongest point of our project team. It allowed us to actually overcome many problems in the past, without causing any detrimental effects on the team. Yes and again division of responsibility proved to be a big headache but we managed to deal with this problem pretty well. The reason for that is actually each of us are willingly to compromise with one another other, and not let our egos get in the way. And I strongly echo your last comment, as I am also quite confident that we can conduct a great software demo.
ReplyDeleteShawn Teo Chee Yong
I want to emphasize on the point of bugs in our software. I do feel we need to improve our whole architecture when we are free. Since I am in charge of the storage part, I have a strong feeling that our system is already very messy in the background.
ReplyDeleteThere are a lot of things inconsistent. I have a very typical example that when we call functions, we need to cast some variables in to String. However, in the called function, we need to cast back to integer. Moreover, we did a lot of transformation between different format of date and time.
Fortunately, we did a good job to finish a lot of bugs by making patches. Although this makes our program not so elegant and easy to maintain, we cover them well with the interface. However, to make Planit a really useful software instead of a school project, we need to do far more works.
For me, I would always support the idaa of using live presentation during our demo. To make some cool introduction video for our program is not something hard, everyone can do it. But what I concern most when I watch those videos is "are they really true?". The fact is that I saw a lot of interesting, nice videos with good motion effects but the values that really come to users, what make program valuable does not lie in that. Instead, why don't we use this demo as a chance to show the users our program, how easy to use it, how helpful it is to their lives? Maybe you're afraid of unexpected troubles during the demo, e.g. the computer stop running or halt (one minute deadtime in live demo is really an end point to the demo), but I think if we prepare carefully, we can pass it. Moreover, due to the small scope of the project and the audience, I prefer the live demo.
ReplyDeleteFor the bugs, it's a matter of time before we clear all of them. Every program has bugs, and what we can do is try our best to minimize the bugs that users may encounter when using our program.