Today � Writing Assignment Update � Final Reflective Statement � Due March 14 � 750 words CSE 481b � Final Project Presentations Winter 2007 � Delivering a software product What we don’t teach you CSE 481b � How to create a successful software � Build a prototype application product � Convince management you could build a successful product � Management Pitch � High Stakes � Single presentation Take away Group A � What is the one thing that you want management to remember
Group B Group C Group D Presentation structure � You’ve done something cool � You’ve done something important � You’ve got a vision of where it could go � Reality check Developing a Conveying value presentation � Only a few of you will present – but all of � Presentation must show that product you should be involved in planning the conveys value to the customer presentation � Describe context � Describe problem being solved � Give a compelling demo � Doing a demo in terms of scenarios is likely to be more effective than a demo in terms of features
Demo hell in Houston Classroom presenter demo A tale of two demos Tablet PC Lab � Network issues known to be challenging � Unknown hardware � SIGCSE, March 3 � Unknown access point � Unknown environment � RJA – Classroom Presenter demo in Tablet � Limited pre-conference testing on hardware PC lab � Lab setup delayed until Friday morning � Instructor machine loses connection midway � Multiple users on the lab with different networking through requirements � VNR – Classroom Presenter lecture � Lab fully scheduled � Instructor machine blue screens � Classroom technology demos � Self paced labs Tablet PC Lab demo � Initial testing showed severe connectivity problems with 12 machines � Various settings were corrected without significant improvement � Lab in partial use limiting testing and other (non presenter) issues require attention � Lab users also changing settings on machines � Decision made to isolate lab machines � Several potential fixes identified � Change machine to 802.11b (from 802.11g) � Connect presenter machine to access point Disasters Tablet PC lab � Demo started fine with about 25 machines � Causes of disasters � Midway through connectivity lost often very complex � The remainder of the presentation given from � Many causes slide decks contribute to � After demo, the networking specialist said he disasters knew what went wrong � Immediate causes � Failure to set static IP address on presenter vs. structural machine causes
What went wrong Disaster recovery � Risks known in advance � After fault was detected: � Continued to have people work on activities – but � Hard questions just from the public display � Why didn’t RJA insist on full system testing � Shifted to slides for final portion of presentation before conference? � Did not attempt to fix the fault � Why didn’t RJA use ad hoc networking? � Used backup plan � Did not attempt to explain the issue to audience � No excuses � Audience was not aware of the fiasco Lessons Classroom Presenter Talk � Delivered talk with classroom presenter � Test risky systems – identify problems early � Passed around 6 tablets for participants to use for exercises � Full system tests � Used our own tablets with ad hoc � Allow on site testing time networking � Have multiple levels of backup available � Started up all Tablets well before the talk � Know when to go to backup plan � VNR delivered talk, RJA was the techie The talk Why this problem was different � Five minutes into the talk, the presenter � Testing and plenty of time for setup machine blue screens � Operating in comfort zone of technology � Just before first classroom activity � Separation of responsibility between demo � Recovery and tech support � Switch in new machine � Change to instructor mode � Set aside failed machine � (it did come back to life) � Continue the talk while RJA dealt with technology � Reconnect the machines and include the activities
Why demos matter Delivering a software product � Most effective way of conveying what a � Computer Science is only a small part of product does the picture � Very easy to get it wrong � Could easily be an important part of your job When is the product Release model done? � External deadlines � Mechanism for delivery of product � Release criteria � Business model � Functionality � Update model Installation model Installation � What expectations do the users have for � The users first experience the installation process? � Delaying gratification � Any number of things can go wrong � Configuration and dependencies � What expectations can you have about � Systems capabilities the users process in installation � Bugs in the process � Unexplained steps
User initiation Beginner, intermediate, expert � Standard model � Design to allow a quick transition from beginner to intermediate � Beginner � Don’t expect beginners/intermediates to � Intermediate read the manual � Expert � Challenge of satisfying all three classes � Most of the user base will remain as intermediates � Without alienating any of them � Expert users are important Product Maintenance Feedback from users � When its done – the work is just beginning � Building community � Bug fixes � Support channels � Updates � Providing additional value and services � The next version
Recommend
More recommend
