What (I Hope That) You Learned This Semester

Writing a critique:

• The purpose of a critique: to support the author in improving the document
• Think like a co-author: what sort of feedback would you find most useful?
• Be specific
• Make specific suggestions for improvements
• A critique includes both positive and negative comments
• Negative: point out what needs to be improved, and how to improve it
• Positive: point out what’s good, so that they continue doing that

• Critique the deliverable, not the authors
• NOT: these authors clearly know nothing about effectively using tabs
• INSTEAD: tabs are not used effectively because…
• Focus the critique on the content of the deliverable, not the document’s appearance
• …unless appearance affects the intelligibility or effectiveness of the deliverable
• don’t give me a line-by-line list of typos and mis-spellings
• The critique must be an essay, not a series of bullets or phrases
• Spell-check and proof-read your critique essay
• Possible organizations for critique:
• Positive points, then negative points
• Follow the organization of the deliverable, with positive/negative points grouped together for each portion of UI design/deliverable
• You can include a critique of portions of the deliverable beyond the paper prototype, but please focus on the UI design
• PLEASE put your name on the cover sheet ONLY, so that it is easier for me to anonymize the critiques.

The Final Deliverable: documenting your work for the semester

• Title page

• Executive summary

• Introduction
• description of client
• why is a new IS needed?
• benefits of a new system (including feasibility analysis); tangible and intangible benefits

• Requirements analysis
• current system description
• new system’s description (what it does, what business tasks/processes that it supports)
• functional requirements (including Use Cases), constraints, non-functional requirements
• new system description should be up to date (that is, incorporating all changes that you’ve made to functionality that you will support, what you’ve learned about the constraints, etc.)

• System design
• UI design (purpose of each screen/report/form, UI navigation diagram, include updated screen dumps from prototype)
• Other issues: backup/recover/arching policies, installation, documentation, support
• Don’t forget the reports!
• Should be up to date

• Database design
• EER diagrams, normalized relational schema, normalization achieved, Access table design, etc.
• Again, be sure that this is up to date

• Testing and test results
• testing schedule (as followed), analysis of results
• modifications made to prototype
• future work suggested by testing

• Conclusion

• Appendices
• Include a profile of your group
• Do not need to include user manuals

• Hand in a copy of your software prototype on a CD

This is just a suggested organization. You may re-arrange these units as you desire, to make the final document “flow”.

Include “why” material as well as “what” material: for example, describing why you made certain design decisions in the UI, as well as describing what the UI looks like

Final deliverable marking scheme:

The final presentation

• 30 minutes max: 20-25 minutes speaking, 5 minutes presenting
• Tight schedule: time spent setting up must come from your total presentation time
• A formal presentation!
• Invite your client, but no worries if they can’t attend

• Suggested organization:
• Client, main problems of client that your system addresses
• Benefits of your system
• Brief overview of functionality of your system (what business processes, functions it supports)
• Demo of your system
• Conclusions

• Mechanics of the presentation:
• Demos are hard to arrange! Will you need to bring in a laptop? Make sure that you demo works BEFORE presentation day
• Brace yourself for the fact that all demos flop over at some point. Be prepared with backups (OHPs, PPT mockups). Don’t get flustered; the audience also knows that all demos flop over.
• Carefully script your demo; know what data you’ll type in, the order in which you’ll demonstrate the functions, etc.
• If you’re doing the talking for the demo, have someone else do the clicking for the demo. Otherwise, you’ll talk down into the monitor.
• Look at the audience, not at the monitor or behind you to the screen.
• Smile!

• What (I hope that) you learned this semester:

• how to organize working with others
• the importance of documentation (OK, actually it's important to do it for other people, later on)
• the usefulness of ‘standard’ environments and tools
• how to manage client expectations
• to look up information that you need to solve a problem—before you really really need it
• to always keep learning
• not to dread public speaking
• even a small project is big if you really do it right

Other IS stuff that we didn't have time to talk about:

• managing information over time

• how to wring out the most information from your raw data (data mining, machine learning)

• how to summarize and present data so as to make it understandable (visualization)

• special problems involved in working with large amounts of text (information retrieval, digital libraries, content management)

• how to set up efficient databases (cool hacky tricks)

• finding out how well your system actually works in practice (usability)

• processes for improving the chances that your program will really work and be great (software engineering methodologies)

• how to set up a beautiful and usable interface (HCI/CHI)

• how to keep bad people from getting your information (data security)

• how to ensure that you put good data into the DB, and that it stays good (data quality)