Live-Demo in der Projektpräsentation

Live-Demo in der Projektpräsentation

Immer mal wieder kommt von Prüflingen die Frage, ob man in der Projektpräsentation nicht auch eine Live-Demo der erstellten Anwendung zeigen könnte.

Die kurze Antwort: Es kommt drauf an, ob du dir genug Zeit nimmst, um die Demo vorzubereiten.

Eine Live-Demo ist immer ein Risiko

Grundsätzlich finde ich, dass eine Live-Demo die Präsentation durchaus aufwerten kann. Gerade, weil man demonstriert, dass man die Anwendung auch wirklich programmiert hat und sie lauffähig ist. Dennoch rate ich den meisten Prüflingen von einer Live-Demo in der Abschlusspräsentation ab.

Warum? Weil einfach zu viel schiefgehen kann:

  • Die Anwendung stürzt ab.
  • Das Programm verhält sich nicht wie erwartet.
  • Es kommt zu langen Ladezeiten.
  • Das Internet ist nicht verfügbar.
  • Die Datenbank ist nicht verfügbar.
  • Der Browser möchte plötzlich Updates installieren.

Denk immer an Murphys Gesetz:

Alles, was schiefgehen kann, wird auch schiefgehen.

Aber das sollte besser nicht bei deiner Abschlusspräsentation passieren!

Die Präsentationszeit wird nicht eingehalten

Eine Live-Demo verführt die meisten Prüflinge dazu, zu lang oder zu kurz über die Anwendung zu berichten. Vielen Prüflingen fällt z.B. zum Zeitpunkt der Demonstration noch ein spannender Button auf, den sie unbedingt noch erläutern müssen, oder sie vergessen einen wichtigen Punkt zu erwähnen. Und schon ist die vorhandene Präsentationszeit überzogen oder nicht ausgenutzt.

Und das muss dann meiner Meinung nach zu einem Punktabzug führen. Ich habe an anderer Stelle schon erläutert, warum man die verfügbare Zeit unbedingt einhalten sollte: Einhaltung der Vortragszeit (15 Minuten) bei der Projektpräsentation.

Der Anteil der Live-Demo an der Gesamtzeit ist zu groß

In der Projektpräsentation solltest du alle wichtigen und interessanten Elemente deiner Projektarbeit vorstellen. Das lauffähige Programm ist nur ein Punkt von vielen, der in die Präsentation gehört. Zusätzlich sind z.B. noch die Projektplanung, die Wirtschaftlichkeitsbetrachtung, die Datenmodelle, der Entwicklungsprozess, Code-Beispiele usw. wichtig. Für eine Vorstellung des Programms solltest du dir also im Verhältnis zu den restlichen Inhalten nicht zu viel Zeit nehmen. Denn letztlich zeigen viele andere Inhalte (z.B. ERM, UML-Diagramme, Amortisationsrechnung, Nutzwertanalyse) deine methodische Arbeit sehr viel besser als das fertige Programm (auch wenn viele Prüflinge das sicherlich anders sehen).

Eine Live-Demo ist tendenziell recht lang im Vergleich zu den 15 Minuten Präsentationszeit. Allein für das Umschalten zwischen Präsentation und Programm gehen schon ein paar wertvolle Sekunden drauf (s.u.). Und im Programm zeigt man dann gerne eher etwas mehr als weniger. Dadurch müssen dann meistens andere interessante – und für die Bewertung relevante – Inhalte gekürzt oder ganz weggelassen werden. Und das ist nicht sinnvoll, wenn du eine gute Note erreichen willst.

Es ist wichtig zu verstehen, dass bei der Projektarbeit und der Projektpräsentation nicht das fertige Programm bewertet wird (siehe auch Muss das Abschlussprojekt erfolgreich und lauffähig sein?), sondern dein methodisches Vorgehen, das Anwenden von Techniken der Softwareentwicklung, die Projektplanung usw. Es geht um das Gesamtpaket und nicht nur darum, Code zu produzieren, der auch läuft. Sicherlich ist das ein wichtiges Ziel, das auch „abgehakt“ werden muss, aber in der Projektpräsentation würde ich nicht den Schwerpunkt darauf legen.

Nerviges Umschalten zwischen Präsentation und Programm

Ein weiteres Problem mit Live-Demos ist das (meist sehr unprofessionelle) Hin- und Herschalten zwischen Präsentation und Programm.

  • Meistens läuft nach dem Zurückschalten die Präsentation nicht sauber weiter, was zusätzliche Sekunden kostet.
  • Oder der Bildschirm ist erweitert und das Programm nicht auf dem Beamer sichtbar bzw. der Prüfling muss es erst auf den anderen Bildschirm schieben und kann es dann nur hakelig steuern.
  • Oder die Auflösung ist so klein, dass die Menüeinträge im Programm gar nicht gelesen werden können.

Alles das kannst du verhindern, indem du einfach Screenshots der Anwendung in deine Präsentation einbaust.

Screenshots der Anwendung als erste Wahl für die Projektpräsentation

Meine klare Empfehlung lautet also: Setze auf Screenshots deiner Anwendung. Dabei kannst du selbst steuern…

  • was du zeigst
  • wie lange du auf die einzelnen Punkte eingehst
  • wie du die Inhalte am besten lesbar darstellst
  • welche Inhalte evtl. nicht sichtbar sein sollen (Stichwort Datenschutz)

Bitte nutze aber die gesamte Präsentationsfläche für deine Abbildungen und quetsche sie nicht zwischen Firmenlogo und Fußzeile. Und schneide alles Unwichtige (bei Webanwendungen z.B. die Menüleiste des Browsers) aus.

Eine Beispielfolie könnte wie folgt aussehen (falls es sich um eine Webanwendung handelt):

Beispiel für eine Folie mit einem Screenshot der erstellten Webanwendung

Aufwertung der Präsentation durch eine Live-Demo

Falls du deine Live-Demonstration vor der Präsentation aber intensiv übst und dir 100-prozentig sicher bist, dass du deine Zeit einhalten wirst, spricht nichts gegen eine Live-Demo.

Im Gegenteil: Das wertet eine Präsentation, die sonst nur aus Folien besteht, deutlich auf. Und natürlich möchten die meisten Mitglieder der Prüfungsausschüsse auch gerne mal etwas „Echtes“ sehen, und nicht nur Folien.

Screencast als Alternative zur echten Demo

Als Alternative zu einer echten Live-Demo besteht aber auch die Möglichkeit, einen Screencast der Anwendung aufzunehmen. Dabei kannst du dir sicher sein, dass nichts schief läuft und du hältst ganz sicher auch die vorgegebene Zeit ein. Das ist auch eine sehr gute Alternative zu „langweiligen“, statischen Folien mit Screenshots.

Außerdem kannst du mit Screencast-Software, wie z.B. Camtasia Studio*, Elemente in das Video einbauen, die…

  • Menüeinträge hervorheben
  • in bestimmte Bereiche hineinzoomen
  • nette Effekte für Übergänge erzeugen
  • lange Aktionen im Zeitraffer zeigen

Dadurch unterstützt du sogar noch das Verständnis beim Prüfungsausschuss und zeigst deine Medienkompetenz.

Live-Demo nach der Präsentation

Als letzte Alternative zur Live-Demo während der Präsentation kannst du in deine Folien ein paar Screenshots der Anwendung einbauen und sie grob beschreiben (damit dieser Punkt für die Bewertung „abgehakt“ ist), dann aber dem Prüfungsausschuss nach deinen 15 Minuten anbieten, optional noch eine Live-Demo vorzuführen.

Wenn der Ausschuss zustimmt, geht die Demo nicht von deiner Zeit ab, und du hast trotzdem dein echtes Programm gezeigt. Das haben in meinem Ausschuss schon mehrere Prüflinge so gemacht. Insbesondere wenn etwas entwickelt wurde, das mit Hardware interagiert, will der Prüfungsausschuss das Ergebnis meistens sehr gerne sehen. Und die paar Minuten nach der eigentlichen Präsentation werden dann gerne in Kauf genommen.

Fazit

Wenn du dich intensiv auf deine Abschlusspräsentation vorbereitest, und sie mehrfach mit einer Stoppuhr durchspielst, spricht nichts gegen eine Live-Demo.

Wenn du aber einfach ungeplant dein Programm vorführst, kann das eigentlich nur nach hinten losgehen. Dann lass lieber die Finger davon.


Planst du eine Live-Demo für deine Projektpräsentation oder hast schon eine gezeigt? Was sind deine Erfahrungen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax