CIS 422/522
How to Present Your Project in Class

A. Hornof - February 1, 2023

[The only updates on 2-1-2023 were (a) to add the section "LIVE DEMO" and (b) to change "REAL DEMO" to "REAL TASK".]

This document summarizes how to do group presentations for CIS 422 Software Methodologies. The document starts with the grading worksheet that will be used to evaluate your presentations, and is followed by a discussion of what and how to present.

Presentation Grading Worksheet

Group: ________________________________________     Date: ___________________

It is the responsibility of all group members to ensure that all of these criteria are met. You should practice your presentation, ideally in the actual classroom with the exact technology that you will use for your presentation, with all group members monitoring all of these criteria. You may help each other during the presentation (such as to ask a group member to move closer to the slide if they are pointing at something from far away).

Evaluation of Participation

Y / N - SHOW UP. All group members should be present.

Y / N - EVERYBODY SPEAKS. All group members should speak for roughly the same amount of time.

Y / N - FULL NAMES. The first slide should list all group members, including their first and last names. At the start of the presentation, all group members should introduce themselves with their first and last names.

Evaluation of Intellectual Content

Y / N - WHAT. Explain what you did, as described below under "What and How to Present".

Y / N - HOW. Explain how you did it, as described below under "What and How to Present".

Y / N - DO A DEMO. There should be a demo of the software. The demo should quickly and clearly convey how the software works.

Y / N - LIVE DEMO. The demo should be live, with the presenter interacting with the software in real time, not a video of the software running.

Y / N - REAL TASK. The demo should show a user doing a real task motivated by a real human need, with real data, not just clicking through the software with random meaningless button presses and keystrokes.

Y / N - NO LOGIN. The demo should not show a user logging in with a username and password. Write software that does not require a login, or log in before starting your presentation.

Y / N - UNIQUE TECHNOLOGY. The presentation should discuss technology as it is applied to this specific project, not how the technology is used to build a generic software program.

Y / N - UNIQUE WORK. Present information that is unique to your group's work, what you did that was different. For example, do not spend more than 10 seconds describing the assignment that everyone did, or the technology that everyone used.

Evaluation of Visual Materials

Y / N - READABLE TEXT. All text used in the presentation should large enough to be readable from the rear of the classroom by a student with typical (20/20) vision. This includes text in diagrams and demos.

Y / N - READABLE DEMO. In the demo, the screen should be resized in so that all text is readable from the rear of the classroom.

Y / N - SLIDES MAKE POINTS. Every slide should make a main point, with substantial information on the slide supporting the main point.

Y / N - USEFUL SLIDES. Visual material should convey the major points of your talk, and also provide substantial supporting material. Viewers should be able to just read the slides, with no audio, and understand the main points as well as the support for the main points. Do not use the Powerpoint "build" feature to reveal one bullet point at a time.

Y / N - NO CHARTJUNK. All of the visual images should be directly relevant to the project, and should help to explain your main points. Every pixel on the slide should either help to explain the points you are making, or should structure the talk (such as with slide numbers). If you show a photograph, the photo should directly support and help to explain a point you are trying to make. Do not use clip art unless it helps to make a point.

Evaluation of Quality of Presentation

Y / N - FINISH ON TIME. Finish within the allocated time.

Y / N - POSITIVE ATTITUDE. Present with a positive attitude. For example, do not sarcastically call attention to how you are fulfilling all of the presentation requirements listed here. Just focus on doing a good presentation.

Y / N - POINT WITH PRECISION. Direct the audience's attention to the things you are talking about. If you are talking about a module in an architectural diagram, don't just wave your hand in the direction of the slide from six feet away. Instead, move your pointing hand to within 12" of what you are pointing at. Hold your "upstage" arm steady in the air, pointing at the thing, while your body faces the audience. (If you are giving a remote presentation and you are referring to something on the screen, use your mouse cursor to point at that thing.)

Y / N - DON'T BLOCK. Stand to the side of your slide so that you are not blocking the slide for any of your viewers.

Y / N - PROJECT YOUR VOICE. Speak loudly and clearly. Project your voice. Fill the room with your thoughts and ideas.

Y / N - NO TECHNICAL DELAYS. There should be no preventable technical difficulties that cause more than one minute of delay.

What and How to Present

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 interested in relevant, easy-to-read content, especially content that is unique to your project, and that does more than restate general software engineering knowledge. I am not interested in irrelevant aesthetics such as interesting fonts and colors. 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 unless all of the groups did the same thing for that topic area:

A. Explain what you did

  1. Provide a brief description of the system from the user's perspective, such as the Concept of Operations. However, if every group developed the same system (as in fulfilled the same requirements), do not spend more than 10 seconds on this.
  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. You do not need to show every feature. Please do not show a user logging in with a username and password; this is not an interesting feature to show in a demo, and not a good use of time in a presentation.
  3. Briefly described the technologies used to build the system. If every group used basically the same technologies, do not spend more than 10 seconds on this.

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. • Skip this step if you did not develop the system requirements (such as if they were assigned).
  3. 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.
  4. 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.
  5. 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.

Permit audience members to read ahead on your slides. Do not give "TED" style talks in which you put just one phrase, photo, or idea on a slide. (Unless the photo tells a vivid story of the topic that you are presenting, and you can point out relevant details in the photo.) 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.