1 / 13

ITM 353 Final Project Demos

ITM 353 Final Project Demos. Your Last Assignment. There ’ s one more fun presentation in store for you all: the Transition Readiness Review (TRR) aka your Project Demo. The project demo has various goals: Show the audience that your product works.

aden
Download Presentation

ITM 353 Final Project Demos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ITM 353 Final Project Demos

  2. Your Last Assignment • There’s one more fun presentation in store for you all: the Transition Readiness Review (TRR) aka your Project Demo. • The project demo has various goals: • Show the audience that your product works. • “Sell” the audience on your process and product. • Describe how you would expect this project to be put into service • Mention support requirements/plans.

  3. Project Presentations • Format your presentation like a real product demo; that is, try to "sell" the audience on the product. Demonstrate its features and its business case. • Professor will be there, along with the rest of the class. You may invite Mommy as well, if you want. • Every group member has to participate (i.e., speak) in the presentation. • Don’t present lots of implementationdetails or class materials!!

  4. Demonstrating Requirements • Part of demonstrating your project is to show the audience what it does. Preferably, you’ll show that what it does matches the requirements. • Therefore, focus your presentation around your system qualities/responsibilities/capabilities • Show, directly or indirectly, that your system meets its primary or core responsibilities, goals and requirements. • Don’t be too exhaustive with minor requirements.

  5. Demonstrating Utility • Along with showing off your system, make a case (think sales pitch) for its usefulness. • Show, directly or indirectly, why your system is worthwhile to the customer and/or end users. • What’s the business case for your e-service? • What are the current shortfalls of the way things are done currently that your system improves?

  6. Demonstrating Process • In convincing the audience that your product is good, you may want to bring in some discussion of your awesome project management skills: • How did you schedule the development? Who did what, when, and why? • Describe how much testing you did. • Describe anything odd that happened (dropped requirements, outstanding bugs). • Discuss your quality management techniques. • If your project doesn’t work right, you’ll want explain why and what’s being done to fix this.

  7. Organizing Your Demonstration • Possible organizing themes for your demonstration: • A series of use cases • A series a demonstrations of particular features • A formal summary of your production effort • Have the audience participate; have “hands-on” follow along.

  8. Good Technique • Some good ideas for your product presentation: • Have your system available for live demonstration (this is a must). • Use slides (but not too many!). • Create a script (who, when, which jokes, etc.), and rehearse it. • Every group member must present something. Work together; have fun and be interesting.

  9. WOW: to do • Things to do for WOW: • Juxtapose your system and its predecessor. • Demonstrate a really cool feature. • Demonstrate an implemented evolutionary requirement (or any other instance of doing more than you had to). • Script your presentation for maximum effect (hook, exposition, rising tension, climax, denouement). • Describe a particular implementation element that your audience will consider difficult (ie, impress us with your god-like skills).

  10. WOW: not to do • Things that will definitely not be WOW: • Excessive description of implementation details. • Boring stuff. Reading from slides!!!! • Avoiding hard questions. • Carefully not revealing bugs. • Demonstrating a visually ‘unappealing’ product. • A disorganized/unprepared presentation. • A very long presentation. Be aware of how much time you’re taking, and be willing to leave some things out. Presentations should not go over 20 minutes.

  11. Demonstration as Song+Dance • Remember that you’re selling your product to your audience: • Let your pride in your product show. Convince your audience why your system is the best. • A certain amount of showmanship and flashy (but tasteful) presentation will serve well. • Remember to smile! 

  12. Demonstration as Technical Review • A product demonstration is your chance to show off the difficulties in your system, and all the hard work you did. • It’s also the chance for support staff (the poor buggers who get to maintain your stuff) to ask questions about your implementation and process. • Be prepared to defend (give rationale for) your system, and answer questions about it.

  13. Summary • Specific requirements for your presentation: • Your product! (a working, if not complete, version) • A salesman-like discussion of your project’s usefulness, from your business case, etc. Why is the system going to be Really Great™ for your client? • A discussion of how you got to where you are: what tools and techniques did you use? • Transition issues: if you’ve delivered, how did it go? If not, when? What is your transition plan. • Support issues: how will you support the product, once it’s deployed? It’s OK to say that you will never touch it ever again, and everything’s up to the customer. 

More Related