Inhalte der Projektpräsentation – Anwendungsentwickler-Podcast #11

In der elften Episode meines Anwendungsentwickler-Podcasts gehe ich sinnvolle Inhalte der Projektpräsentation durch.

Probeabo bei Audible (Affiliate)

Wichtige allgemeine Hinweise

Die Projektpräsentation sollte im Großen und Ganzen die Inhalte der Projektdokumentation verkürzt darstellen. Meist haben nicht alle Mitglieder des Prüfungsausschusses die Dokumentation gelesen, also sollte die Präsentation ohne dieses Hintergrundwissen verständlich sein. Du kannst davon ausgehen, dass im Prüfungsausschuss erfahrene Softwareentwickler sitzen, musst also keine allgemein bekannten Begriffe erläutern (z.B. GUI, ERM usw.). Aber die Feinheiten deiner Branche, deines Ausbildungsbetriebes und insb. deines Projektumfelds wird niemand kennen.

Da die 15 Minuten – die du übrigens unbedingt einhalten musst – recht knapp bemessen sind, sollten die wichtigsten und interessantesten Inhalte der Dokumentation gezeigt werden. Das sind hauptsächlich die angewendeten Methoden, z.B. in Form von UML-Diagrammen, und nicht langweilige Textwüsten. Super ist eine Live-Demo deiner Anwendung, wobei du sicher sein solltest, dass diese wie erwartet funktioniert. Ich würde daher eher zu Screenshots oder einem Screencast raten.

  • Alle Inhalte müssen gut lesbar sein. Ich empfehle mind. (!) Schriftgröße 24. Achte insb. auf Grafiken und Quelltexte, die genauso groß sein sollten.
  • Nutze woimmer es geht besser Grafiken/Diagramme anstatt Text zur Visualisierung deiner Arbeit. Die hast du ohnehin (hoffentlich) für die Dokumentation erstellt.
  • Zeige interessante Inhalte und Beispiele und keine langweiligen Trivialitäten. Beispiel: Als Quelltextausschnitt nicht die Getter/Setter deiner Klasse zeigen, sondern den selbst entwickelten Algorithmus.
  • Die Corporate Identity (Logo, Fußzeile usw.) mag deinem Ausbildungsbetrieb heilig sein, aber wenn du große Grafiken oder Quelltext zeigen willst und durch das Logo nur noch die halbe Folie an Platz zur Verfügung steht, würde ich zu Gunsten der Lesbarkeit auf die CI verzichten. Denke daran: Es ist deine (!) Abschlussprüfung und keine Werbeveranstaltung deines Ausbildungsbetriebs.
  • Die vorgebene Zeit von 15 Minuten muss unbedingt eingehalten werden.
  • Daher muss eine bewusste Auswahl der Inhalte getroffen werden.
  • Das bedeutet, dass man nur die absoluten Highlights seines Projekts zeigen sollte.
  • Wo immer es geht, mit Grafiken arbeiten und nicht mit Text. Gerade die wichtige Methodik lässt sich sehr gut visualisieren (UML, ERM usw.).
  • Auf jeden Fall muss sowohl die Technik, als auch die Wirtschaftlichkeit gezeigt werden.
  • Wichtige Eckpunkte, die aus der Präsentation hervorgehen müssen: verwendete Programmiersprache und Datenbank sowie ggfs. Frameworks.
  • Fokus auf die eigenen Inhalte legen.
  • Nicht auf ein funktionierendes Internet verlassen!
  • Zwischenfragen nicht zulassen!

Konkrete Inhalte

  • Klassischer Aufbau: Einleitung, Hauptteil, Schluss.
  • Einleitung stellt Prüfling, Betrieb und Thema vor.
  • Hauptteil zeigt die Highlights aus den einzelnen Projektphasen.
  • Schluss gibt einen Rück- und Ausblick.

Einleitung

  • Titelfolie mit Projektbezeichnung, Daten des Auszubildenden und des Ausbildungsbetriebs.
  • Agenda zeigt geplanten Ablauf der 15 Minuten.
  • Kurze (!) Vorstellung des Prüflings und des Unternehmen.
  • Das Projekt und die Aufgaben des Prüflings müssen verständlich erklärt werden, auch für Mitglieder des Prüfungsausschusses, die die Projektdokumentation nicht gelesen haben.
    • Insb. das Projektziel und die Begründung für die Durchführung müssen ersichtlich werden.
  • Kurze (!) Beschreibung der Ausgangssituation (Ausbildungsbetrieb, Problemstellung, Ist-Analyse).
    • Viele Prüflinge nutzen diesen Teil als viel zu lange Werbeveranstaltung für das Ausbildungsunternehmen. Es interessiert niemanden, wie viele Standorte und tolle Produkte dein Unternehmen hat. Du sollst dein Projekt und deine eigene Arbeit vorstellen. Eine Folie zum Unternehmen und maximal ein paar Sätze dazu reichen.

Hauptteil

  • Übliche Grafiken zur Erklärung bestimmter Sachverhalte.
    • ERM, Tabellenmodell für die Datenbank.
    • GUI-Mockup, Screenshot für die Oberfläche.
    • Use-Case-/Aktivitätsdiagramm, EPK oder Flussplan für die Anforderungen.
    • Klassen-/Komponentendiagramm für die Architektur der Anwendung.
    • Deplomentdiagramm für die physikalische Verteilung der Anwendung.
    • Klassen-/Sequenz-/Zustandsdiagramm für die Implementierung.
    • Visuelle Amortisationsrechnung bei der Wirtschaftlichkeitsbetrachtung.
  • Der Aufbau des Hauptteils sollte dem Ablauf des Projekts folgen (Projektphasen).
  • Projektplanung
    • Projektziel (Soll-Konzept, Qualitätskriterien).
      • Hierbei besonders auf den Kontext und das Ziel des Projekts eingehen, das man ohne Vorkenntnisse verstehen sollte. Ich habe schon Präsentationen gesehen, bei denen ich bis zum Ende nicht wusste, was eigentlich genau umgesetzt wurde und warum das sinnvoll war.
    • Projektbegründung: Projektkosten und Wirtschaftlichkeitsbetrachtung (Amortisationsrechnung, gerne grafisch), ggfs. Nutzwertanalyse.
    • Projektphasen mit Angabe der geplanten Stunden
    • Vorstellung des Entwicklungsprozesses
    • Wirtschaftlichkeit: Kosten- und Amortisationsrechnung; ggfs. Nutzwertanalyse
      • Die Wirtschaftlichkeit ist ein absoluter Pflichtteil in jeder Präsentation, auch wenn die meisten Entwickler sich lieber mit der Technik auseinandersetzen.
  • Analyse
    • Vorgehen beschreiben
    • Use Cases zeigen
    • Lastenheft
  • Entwurf
    • Programmablauf: EPK, Aktivitätsdiagramm, Flussplan
    • GUI: MockUps der Oberflächen, Konzept der Dialoge
    • Datenbank: ERM, Tabellenmodell
    • Architektur der Anwendung (Einbindung in und Interaktion mit anderen Systemen): Komponentendiagramm, Verteilungsdiagramm
      • Wie komplex ist die Aufgabenstellung? Welche Komponenten wurden umgesetzt?
    • Entscheidung für Programmiersprache, Datenbank, Frameworks usw. begründen, z.B. mit einer Nutzwertanalyse
  • Implementierung (z.B. ERM, UML, (kurze) Quelltexte, Screenshots).
    • Es ist erstaunlich, dass es immer wieder Präsentationen gibt, aus denen die verwendete Programmiersprache und/oder Frameworks usw. nicht hervorgehen.
    • Auch die Qualitätssicherung ist ein zentraler Punkt. Hast du getestet? Wie? Gab es Code-Reviews? Wer hat das Programm abgenommen?
    • interessante Quelltexte, Screenshots zeigen
    • Endergebnis zeigen: Screenshots, Live-Demo (besser als Video aufzeichnen)
    • Beispiele für aufgetretene Probleme und deine Lösungen dafür.
      • Bitte keine Trivialitäten wie „ich habe bei der for-Schleife einen Off-by-one-Error gehabt“.
  • Test/Abname
    • Testplan, Unit-Tests, Testprotokolle zeigen
  • Dokumentation
    • Benutzerdokumentation vorstellen
    • Entwicklerdokumentation zeigen

Schluss

  • Fazit: Zielerreichung, Akzeptanz beim Kunden
    • Hier kannst du gerne noch kurz (!) deine Erfahrungen unterbringen und ggfs. zeigen, dass das Projekt fortgeführt oder erweitert wird.
  • Lessons Learned: Was hat der Prüfling aus dem Projekt gelernt?
  • Ausblick: Wird das Projekt weitergeführt und wenn ja wie?
  • Obligatorische Schlussfolie mit Name, Logo usw.

Bewertungsschema der IHK

Die IHK bewertet die Präsentation nicht allein, sondern im Zusammenhang mit dem anschließenden Fachgespräch. Es gibt also immer nur eine Note für den gesamten Prüfungstag. Dennoch kann eine gute Präsentation natürlich die Gesamtnote verbessern bzw. eine schlechte das ansonsten gute Fachgespräch abwerten.

Das folgene Bewertungsschema wird von mehreren IHKen verwendet. Allerdings kann jede IHK eigene Vorgaben machen. Bitte suche daher auf der Website der für dich zuständigen IHK nach den konkreten Vorgaben für deine Prüfung.

  • Fachkenntnisse (20%)
    • Die musst du also zeigen! Das bedeutet: Methoden, Kosten, Grafiken, spannende Inhalte.
  • Rhetorik (10%)
    • Ich gehe davon aus, dass du die Präsentation so lange übst, bis du sie perfekt auswendig kannst und exakt auf 15 Minuten kommst. Dann sollte der Vortrag locker und professionell möglich sein.
  • Medieneinsatz (10%)
    • Wie man mit PowerPoint umgeht, solltest du nach drei Jahren Ausbildung wissen. Sinnvolle Animationen sind zur Unterstützung der Verständlichkeit Pflicht.
  • Begrüßung und Einstieg in die Präsentation (10%)
    • Siehe oben: Mache direkt dein Thema deutlich und zeige, was deine Leistung ist. Verschwende keine wertvolle Zeit mit der Historie oder dem Organigramm deines Ausbildungsbetriebs.
  • Ergebnis des Fachgesprächs (50%)

Foliendesign

Zum Thema Foliendesign ist eine allgemeine Empfehlung schwierig. Viele Prüfungsausschüsse werden wohl den „klassischen“ Aufbau der Folien erwarten, also…

  • Kopf-/Fußzeile mit Unternehmenslogo, Datum, Titel etc.
  • Folien sollten der Corporate Identity des Ausbildungsbetriebs folgen
  • ständig sichtbares Inhaltsverzeichnis (als „Fortschrittsbalken“)
  • Stichpunkte als Bullet Points auf den Folien
  • nicht zu viel Text auf den Folien
  • Methoden grafisch dargestellt

Ich persönlich vertrete jedoch einen anderen Ansatz, den du dir hier im Detail anschauen kannst: Ideen für moderne Projektpräsentationen.

Literaturempfehlungen

  • Felicia Ullrich - Ratgeber für die mündliche Prüfung. 10 clevere Tips für die mündliche Prüfung (Affiliate)*
  • Anselm Rohrer - Clevere Tipps für die Projektarbeit – IT-Berufe: Abschlussprüfung Teil A (Affiliate)*
  • Garr Reynolds - Presentation Zen (Affiliate)*

Links

Weitere Infos zur Projektpräsentation

Du suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.

Checkliste für die Projektpräsentation

Jetzt anmelden!

Probeabo bei Audible (Affiliate)

Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

22 comments on “Inhalte der Projektpräsentation – Anwendungsentwickler-Podcast #11

  1. Q sagt:

    Was ist denn mit Maßnahmen zur Sicherung der Qualität?
    Laut dem Bewertungsbogen muss ich das auch vorstellen. Handhabt das jeder anders oder zählt’s als Maßnahme wenn man Tests vorgestellt hat?

  2. Stefan Macke sagt:

    Hallo Q, guter Hinweis. Die Qualitätssicherung gehört selbstverständlich in die Präsi. Darauf habe ich jetzt gar nicht explizit hingewiesen, weil ich davon ausgehe, dass jedes Projekt eine Testphase hat (oder anderweitig für Qualität sorgt, z.B. mit TDD). Also gerne Testabläufe, Unit-Tests, Code Reviews usw. mit in die Präsi aufnehmen. Natürlich im Verhältnis zu den anderen Inhalten. Viele Grüße! Stefan

  3. FAE sagt:

    Hallo Stefan,
    kann ich in meiner Präsentation Inhalt zeigen, den ich außerhalb des eigentlichen Projektzeitraumes erarbeitet habe ?
    Beispielsweise die Berechnung der Amortisierungdauer oder Dinge, die ich im nachhinein an meiner Software erweitert habe…
    Viele Grüße

  4. Stefan Macke sagt:

    Hallo FAE,

    die Amortisationsdauer solltest du während (am besten ganz zu Beginn) der Projektzeit berechnet haben, sonst hättest du das Projekt ja evtl. gar nicht durchgeführt, da es sich nicht rentiert hätte. Das gehört also auf jeden Fall in die Präsentation.

    Mit Erweiterungen am Programm wäre ich vorsichtig, da die Arbeit nicht zu deinem Projekt gehört, das in der Prüfung bewertet werden soll. Im „Fazit“ oder „Ausblick“ kannst du vielleicht darauf eingehen, dass das Projekt fortgeführt wird und sogar schon Erweiterungen entwickelt wurden, aber ich würde das nicht im Hauptteil der Präsentation zeigen. Sonst werden es die Prüfer schwer haben, zu unterscheiden, was deine eigentliche Prüfungsleistung war. Und das ist fast immer negativ für den Prüfling.

    Viele Grüße!
    Stefan

  5. FAE sagt:

    Danke für die schnelle Antwort.

    Nun habe ich die Amortisationsdauer zwar am Anfang des Projektes errechnet aber nicht in der Dokumentation erwähnt. Wenn ich sie nun plötzlich in der Präsentation erwähne, sollte sich das doch ebenfalls negativ auf meine Bewertung auswirken. Es ist dann nunmal nicht klar ersichtlich, ob ich die Leistung während des Projektzeitraumes erbracht habe. Richtig ?

    Viele Grüße

  6. Stefan Macke sagt:

    Das würde ich nicht sagen. Es kommt darauf an, wie du es verpackst. Wir haben oft Prüflinge, die etwas in der Dokumentation vergessen oder nachträglich einen Fehler entdeckt haben. Solange man in der Präsentation darauf hinweist, ist das kein Problem. Und denk dran, dass es auch Prüfer gibt, die deine Doku nicht gelesen haben. Die wissen gar nicht, dass du die Amortisation dort nicht erwähnt hast. Mir würde dann in der Präsentation – die ja separat von der Doku bewertet wird – die Amortisation einfach fehlen. Du kannst einfach darauf hinweisen, z.B. mit „Aus Platzgründen habe ich die Amortisation in der Dokumentation nicht gezeigt, …“ oder ganz ehrlich „Ich habe die Amortisation in der Dokumentation vergessen, aber …“.

  7. FAE sagt:

    Alles klar! Vielen Dank nochmals für die guten Antworten! Super Podcast! 🙂

  8. Zimt sagt:

    Hallo
    Ich habe eine Frage zu Bildquellen. Ich sehe, dass viele nach der Danksagung die Folien mit Bildquellen angeordnet haben. Wird nach der Danksagung , dann noch erwähnt, dass man die Bildquellen noch hinzugefügt hat? Ich weiß nicht, ob ich Bildquellen nicht lieber als Handouts ausgebe.

  9. Stefan Macke sagt:

    Ein Handout finde ich unnötige Papierverschwendung. Und die Quellen gehören ja zur Präsentation und sollten nicht mit einem anderen Medium verteilt werden. Einfach die letzte Folie für die Quellenangaben reservieren und fertig. Du kannst sie auch als Slideshow nach deiner Präsentation automatisch durchlaufen lassen, wenn du eh nichts dazu sagen willst und die Zeit einsparen willst.

  10. Zimt sagt:

    Also im Prinzip muss ich nichts dazu sagen?
    Ich dachte mir wenn ich sie einblende, finde ich das irgendwie blöd zu sagen, danke für Ihre Aufmerksamtkeit, aber ich ich habe noch paar Bildquellen für Sie.
    Oder ich blende sie kurz vor der Danksagung ein ..hmm

  11. Arnulf Hubbuch sagt:

    Wird erwartet, dass man genauer auf die Implementierung eingeht? Oder sollte der Fokus darauf liegen, dass man zeigt wie die Anwendung aussieht und welche Funktionalität sie hat. Schließlich wird in der Doku ausführlich erklärt wie man sein Projekt umgesetzt hat. Von dem knappen Zeitrahmen ganz zu schweigen.

  12. Stefan Macke sagt:

    Wir achten immer darauf, dass alle Bestandteile des Projekts vorgestellt werden. Ich würde also versuchen, aus allen Phasen die wichtigsten Inhalte zu zeigen. Und Quelltext gehört meiner Meinung mit dazu.

  13. Peter Hagl sagt:

    Ich mache auch die Ausbildung zum Fachinformatiker für Anwendungsentwicklung und habe mich für Folien auf einem Overhead Projektor entschieden. Das ist doch auch in Ordnung oder?

  14. Stefan Macke sagt:

    Hallo Peter,

    grundsätzlich bist du bei der Wahl des Mediums frei. Allerdings würde ich mich schon fragen, warum du heute noch mit Folien arbeitest und nicht eine moderne Präsentation erstellst. Aber wenn du deinen Inhalt vernünftig transportierst, ist das Medium zweitrangig.

    Viele Grüße!
    Stefan

  15. Jonas sagt:

    Eine gute projektpräsentation sollte im Team gemacht werden (wie ein Puzzle, wenn ein teil fehlt dann passt es nicht

  16. Stefan Macke sagt:

    …allerdings nicht in der IHK-Prüfung! 🙂

  17. Patrick Eiser sagt:

    Hallo, wollte nur kurz fragen, wie aktuell der Beitrag noch ist und ob dies auch für Systemintegratoren verwendet werden kann oder gibt’s für die einen anderen Beitrag da dieser doch ziemlich für Anwendungsentwickler geschrieben wurde?

  18. dee7kay sagt:

    Hallo Stefan,

    zuerst mal vielen Dank für deine tolle Seite hier. Leider hab ich sie erst jetzt, nachdem ich meine Projektdokumentation schon abgegeben habe und nur noch die Präsentation und das Fachgespräch vor mir habe, gefunden. 😀 Aber da ich gerade dabei bin, meine Präsentation vorzubereiten, habe ich schon sehr viele sehr gute Tipps gefunden.

    Ich habe eine Frage zu den Inhalten der Projektplanung. In meiner Dokumentation habe ich, wie wir das in der Schule gelernt haben, im letzten Kapitel Projektergebnis noch die Ist-Terminplanung (als Gantt-Diagramm) und die angepasste Kostenplanung eingefügt. (Das heißt, ich habe einen Vergleich zwischen der anfangs durchgeführten Planung und der tatsächlichen Durchführung gemacht.)

    Jetzt meine Frage: Zeige ich in der Präsentation die Soll-Termin-/Kostenplanung oder die Ist-Termin-/Kostenplanung?

    Vielen Dank schon mal im Voraus.

  19. Stefan Macke sagt:

    Das kommt darauf an, was du darstellen willst. Für die Projektplanung würde ich den geplanten Plan zeigen und für den Soll-/Ist-Vergleich den tatsächlichen. Du kannst auch nur einen von beiden zeigen. Wie gesagt: Überlege dir, was du eigentlich damit zeigen möchtest und dann entscheide dich für die passende Variante.

  20. Stefan Macke sagt:

    Der Beitrag ist weiterhin aktuell. Speziell für FISIs habe ich keine Artikel. Aber die grundlegenden Inhalte und der Aufbau stimmen eh überein.

  21. Christian sagt:

    Hallo Stefan,
    ich habe in meinem Projekt auf die Amortisierungsberechnung verzichtet. Das Projekt ist Teils eines riesigen Gesamtprojekts, bei dem nichts neues erschaffen wird, sondern was vorhandenes ersetzt wird für Kundenzufriedenheit. Werde ich Abzug bekommen wenn ich erkläre, dass es nicht möglich war das zu berechnen und die Aufgabe eh von meinem Chef kam?

  22. Stefan Macke sagt:

    Mit dieser Begründung („dass es nicht möglich war das zu berechnen und die Aufgabe eh von meinem Chef kam“) würde ich dir einen Punktabzug geben. Warum wollte dein Chef das Projekt? Wenn nicht aus monetären Gründen, welche kannst du stattdessen anführen? Wie kannst du diese Gründe objektivieren (Tipp: Nutzwertanalyse)?

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