CIS 422/522
How to Present Your Project in Class

A. Hornof - April 30, 2019

This document summarizes how to do group presentations for CIS 422 Software Methodologies.

Please come to class on presentation day prepared to present the following, roughly ten minutes per group. You can pre-assign speakers for each topic, but every group member should be prepared to comment on every topic. In other words, every group member should have learned everything that is presented.

Please prepare visuals, which can be in the form of presentation slides or a word processing document that you just scroll through, as I do with my lecture notes. Please  make sure the text is big enough to be seen from the back of the room. I am far more interested in the content than the formatting, especially content that is unique to your project, and that does more than restate general software engineering knowledge. For the last four topic areas below, please try to identify at least one interesting, important, big thing that your group learned about that topic.

Presentation Outline

There are basically seven topic areas, as follows. Please try to spend roughly one minute per topic area:

A. Explain what you did

1. Provide a brief description of the system from the user's perspective. This is a summary of the "concept of operations".
   • If the concept of operations changed since the start of the project, briefly remind us what was the original idea, and how and why the concept of operations changed.
2. Show a demo of the system as a user would use the system to accomplish real-world tasks. Focus on the functionality necessary to accomplish real-world tasks.
3. Briefly described the technologies used to build the system.

B. Explain how you did it.

1. How you established the system requirements. List (a) existing systems (and technology) that you looked at and what you learned by looking at each, (b) who you interviewed, how you recruited your interviewees, and what you learned from each interview, and (c) other sources that you used, other than your guesswork, to establish system requirements.
   • State at least one thing that your group learned about requirements analysis and specification.
2. How you translated the system requirements into a software design (not a user interface design). Describe the process that you used to do this translation. This should include a few diagrams that communicate what is the final design of the software, not from the user's perspective but instead from the programmer's. If you can show early design ideas, and explain how and why these early ideas evolved, that would be very good. Keep in mind that this is not the design of the user interface, but rather of the software components and how they interact.
   • State at least one thing that your group learned about software design.
3. How you integrated and tested your systems. What was the process? How did it go? What went well, and what did not go well? If you conducted any user observation studies, describe them briefly here.
   • State at least one thing that your group learned about software testing.
4. How was the team managed? How was the team experience? What went well and what did not go well?
   • State at least three things that your group learned about working on a team.

Though the questions above may seem long, I trust that the specificity and detail of the questions actually makes the preparation easier than if the questions were more open-ended.

Visual Materials

Visual materials in a presentation should be used to state all of the main points that you want to make and, in addition, to offer additional information that audience members can read and study, if they choose, while you are speaking. Do not use your slides as bullet points to remind yourself of your topics but instead to make complete statements, and to show additional details and diagrams, including statements and diagrams that you may not have time to comment on.

Remember that your audience in this class is a group of highly-skilled learners. Permit audience members to make moment-to-moment choices about whether they will learn more by focusing on what you are saying or by focusing on detailed visual information that you are displaying; perhaps you will say something briefly that the audience member can learn more about by studying the slide. To this end, do not give "TED" style talks in which you put just one phrase, photo, or idea on a slide. (Unless, for example, the photo tells a vivid story of the topic that you are presenting.) And do not use the "build" feature of presentation tools such that you reveal one bullet at a time unless there is a content-related reason to temporarily hide some information, such as you want audience members to consider a question before you give the answer.

Do not use clip art in your presentations. It is not scholarly, it wastes space, and it distracts from the relevant content.

In general, fill the entire slide with content. Slide titles should state the main point of the slide and take a minimum amount of space. The rest of the slide should be filled with content. If you have extra white space, enlarge the text to fill the slide; this is a particularly good idea if you do not know far in advance what the room layout will look like, and the screen might turn out to be quite small.

Diagrams should be scaled so that their text is about as large as the text you are using throughout your presentation. In general, each diagram should fill as much of the slide as necessary to accomplish this and, if necessary, be shown first on one slide in its entirely and then on multiple follow-up slides broken out into smaller pieces.

When you present a diagram or a graph, always state what it, both on the slide and verbally. Graphs with an x-y plot should always be introduced by "This graph shows <x> as a function of <y>." Remember that this is the first moment that the audience will be seeing these images and need to be oriented as quickly as possible.

When presenting, do not point with your arm from the podium. Nobody will know what you are pointing at. Instead, either (a) stand to the side of the screen with your whole body facing the audience and not blocking anyone's view, and use your "upstage" arm to point to the relevant content or (b) use some sort of remote visual tool to point at screen content, such as laserpointer or mouse pointer. When using a laser pointer, point for about half a second and then turn off the laser.

Do a "Tech Rehearsal"

Whenever possible, in advance of giving your presentation, visit the exact venue where you will be presenting and do a full "tech rehearsal" exactly as you would ultimately deliver the presentation. This will help to get accustomed to room acoustics, site lines, and the technology that will be used during the actual presentation. It also does wonders to calm your nerves on the day of the performance. I have seen countless high-stakes presentations and performances fail in which, I suspect, the performer did not do a full tech rehearsal. (I once performed at a high-stakes computer music venue in New York City in which I insisted on a full tech rehearsal despite the protests of the technicians themselves. My run-through revealed a major electrical problem with the stage wiring that the technicians then scrambled to fix in advance of the actual performance, apologizing profusely. Feel free to ask me about this and I will tell you the story.) You owe it to yourself to, if your presentation fails, to be able to say "Well, at least I did everything I could to prepare."