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:

5 / Title page, Introduction, Conclusion
20 / Structured Requirements (including benefits of new system)
15 / Database design
20 / User interface design
15 / Testing procedure and test results
25 / Implemented prototype

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)