IT-Berufe-Podcast

Die Inhalte meiner Lernzielkontrolle zum Thema HTML sind das Thema der dreiunddreißigsten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit meiner Lernzielkontrolle zu HTML kannst du Grundlagen wiederholen, die für dich als IT-Azubi in der Anwendungsentwicklung und für deine Abschlussprüfung relevant sind. HTML steht für Hypertext Markup Language und gibt verknüpften Texten durch Tags eine Bedeutung. Dazu gehören die Syntax mit Elementen und Attributen sowie der Dokumentbaum, auf den JavaScript über das DOM zugreift. Weitere Themen sind DOCTYPE, XML und valide Dokumente; semantisches Markup hilft Suchmaschinen und Screenreadern dabei, deine Inhalte zu verstehen.

Kapitelmarken

[00:00:01] Einstieg: Lernzielkontrolle zu HTML

[00:00:25] HTML in Ausbildung und Abschlussprüfung

[00:01:32] HTML und Hypertext

[00:03:01] Auszeichnungssprache und Semantik

[00:04:57] Syntax: Tags und Elemente

[00:06:35] Kommentare in HTML

[00:06:59] HTML-Entities und UTF-8

[00:09:27] Attribute und Anführungszeichen

[00:10:27] Leere Elemente und empfohlener Schreibstil

[00:12:05] Dokumentbaum mit html, head und body

[00:14:11] DOM und dynamische Inhalte mit JavaScript

[00:15:11] DOCTYPE und HTML5

[00:16:14] XML als erweiterbare Auszeichnungssprache

[00:17:37] W3C, DTD und HTML-Standards

[00:19:31] Wohlgeformtheit und Validität

[00:21:42] Semantisches Markup in HTML5

[00:23:16] Suchmaschinen und Barrierefreiheit

[00:24:56] Passende Elemente für deine Inhalte

[00:25:48] Fragen und begleitende Links

[00:26:29] Ausbildungsplan als Excel-Datei

[00:27:02] Git-Workflows

[00:27:24] Feedback und Fragen zur Ausbildung

[00:27:56] Newsletter und Checklisten zur Prüfung

[00:28:30] Ausblick: Mündliche Ergänzungsprüfung

Inhalt

HTML: Hyptertext Markup Language

Was ist Hypertext?

Was ist eine Auszeichnungssprache?

Syntax: spitze Klammern, Kommentare, Entities

Tags, Elemente, Attribute

Baumstruktur und DOM

HEAD und BODY

DOCTYPE

Unterschied zu XML

Wohlgeformtheit und Validität

semantisches Markup

Neuerungen in HTML5

W3C

Literaturempfehlungen

Mit dem Buch von Brian Hogan* habe ich selbst vor einigen Jahren HTML5 und CSS3 gelernt. Es ist inzwischen natürlich etwas in die Jahre gekommen. Da es recht kurz ist, empfehle ich es meinen Azubis als gute Einstiegslektüre.

*

Wer aber die volle Dröhnung HTML haben will, dem sei eher das Handbuch aus dem Rheinwerk Verlag* mit über 1.000 Seiten empfohlen. Da bleibt keine Frage offen ;-)

*

Jürgen Wolf - HTML5 und CSS3: Das umfassende Handbuch beim Rheinwerk Verlag

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Zeichensätze und -kodierung - Anwendungsentwickler-Podcast #32

HTML5 Reference

HTML 4 Document Type Definition

Hypertext Markup Language – Wikipedia

Hypertext – Wikipedia

HTML5 Style Guide

Extensible Markup Language – Wikipedia

Document Object Model – Wikipedia

World Wide Web Consortium – Wikipedia

Zusammenfassung

HTML in Ausbildung und Prüfung

Ich prüfe mit meinen IT-Azubis regelmäßig die Themen, die sie zuvor gelernt haben. Beim Thema HTML gehören dazu Grundlagen, die auch in der schriftlichen oder mündlichen Abschlussprüfung vorkommen können. Wenn du als Fachinformatiker:in Anwendungsentwicklung ein Webprojekt für deine Abschlussprüfung umsetzt, solltest du diese Begriffe erklären können.

Was HTML bedeutet

HTML steht für Hypertext Markup Language.

Hypertext bezeichnet Textdokumente, die durch Links miteinander verbunden sind. Ein Klick führt dich von einem Dokument zu einem anderen. Tim Berners-Lee entwickelte dieses Prinzip am CERN, um zusammengehörende Forschungsdokumente zu verknüpfen.

Eine Markup Language, also eine Auszeichnungssprache, gibt Textbestandteilen eine Bedeutung. Mit h1 kennzeichnest du beispielsweise eine Überschrift, mit p einen Absatz. Diese Bedeutung heißt auch Semantik.

Browser interpretieren die Elemente und stellen sie entsprechend dar, etwa mit einer großen Überschrift oder einem Abstand nach einem Absatz. Auch LaTeX arbeitet mit dem Prinzip, Textbestandteilen eine Bedeutung zu geben. HTML dient dazu, Inhalte auszuzeichnen; die für das Programmieren beschriebenen Kontrollstrukturen wie Schleifen und Verzweigungen fehlen.

Tags, Elemente und Kommentare

HTML-Tags stehen in spitzen Klammern. Ein öffnendes Tag sieht beispielsweise so aus: . Beim schließenden Tag steht ein Slash vor dem Namen: .

Das vollständige Element umfasst die Tags und den Inhalt dazwischen:

html

Meine Überschrift

Ein Tag bezeichnet dabei die einzelne öffnende oder schließende Markierung.

Kommentare schreibst du mit am Ende:

html

Damit kannst du auch Teile eines Dokuments auskommentieren, wenn du etwas testest.

Sonderzeichen und HTML-Entities

Wenn ein Zeichen im HTML-Kontext eine besondere Bedeutung hat und als Text erscheinen soll, kannst du es als Entity schreiben. Benannte Entities beginnen mit einem kaufmännischen Und, gefolgt von einer Abkürzung und einem Semikolon. Beispielsweise steht > für das Größerzeichen >.

Für Umlaute und viele weitere Sonderzeichen gibt es ebenfalls Entities. Bei einem passend kodierten UTF-8-Dokument kannst du deutsche Umlaute direkt schreiben. Ich empfehle Entities für Zeichen, die HTML sonst als Teil seiner Syntax interpretieren würde.

Attribute und Schreibstil

Attribute stehen im öffnenden Tag und ergänzen ein Element um Eigenschaften. Du schreibst sie als Schlüssel-Wert-Paare, etwa schlüssel="wert", wobei Leerzeichen mehrere Attribute voneinander trennen.

Ich empfehle, Attributwerte immer in Anführungszeichen zu setzen. Das macht den Code lesbarer und verringert Fehler. Enthält ein Wert Leerzeichen, sind die Anführungszeichen erforderlich.

Bei Elementen ohne Inhalt, beispielsweise hr für eine horizontale Linie, bevorzuge ich die Schreibweise . Diese Empfehlung orientiert sich an der XML-Syntax und an dem verlinkten HTML-Styleguide. Auch die Tags für head und body schreibe ich ausdrücklich ins Dokument.

Dokumentbaum und DOM

Ein HTML-Dokument hat eine Baumstruktur, deren Wurzelelement html ist. Darunter liegen head und body:

Im head stehen Kopfdaten und Metainformationen, beispielsweise Angaben zur Zeichenkodierung.

Im body stehen die sichtbaren Inhalte, darunter Texte und Bilder.

Weitere Elemente werden darin verschachtelt. Ein Ast enthält untergeordnete Elemente; ein Blatt hat keine weiteren Elemente unter sich.

Das Document Object Model, kurz DOM, definiert, wie Programme auf diesen Baum zugreifen können. Mit JavaScript kannst du beispielsweise Kind- und Elternelemente auslesen oder Inhalte verändern. Wenn du per AJAX einen Blogartikel vom Server nachlädst und in den bestehenden Baum einfügst, aktualisiert der Browser den betroffenen Teil der Seite.

DOCTYPE, XML und Standards

Am Anfang eines HTML-Dokuments steht der DOCTYPE, der die verwendete HTML-Version kennzeichnet. Für HTML5 lautet er:

html

XML steht für Extensible Markup Language, also erweiterbare Auszeichnungssprache. Damit kannst du eigene Elemente und Attribute festlegen und deine Sprache erweitern. Die Syntax arbeitet ebenfalls mit Tags in spitzen Klammern.

Für HTML sind die erlaubten Elemente und Attribute durch einen Standard festgelegt. Das W3C, ausgeschrieben World Wide Web Consortium, wird als Gremium beschrieben, in dem Unternehmen und weitere Beteiligte solche Standards abstimmen.

Bei XML können eine DTD, also Document Type Definition, oder ein XML-Schema die Regeln einer Sprache beschreiben. Für ältere HTML-Versionen existieren DTDs. HTML5 hat keine DTD, weil deren Möglichkeiten für bestimmte Regeln zu eingeschränkt sind. In den begleitenden Links findest du eine HTML5-Referenz sowie eine ältere HTML-DTD.

Wohlgeformt und valide

Bei XML gehören Wohlgeformtheit und Validität zu den Begriffen, die du auseinanderhalten können solltest:

Wohlgeformt bedeutet, dass ein Dokument die syntaktischen Regeln erfüllt. Dazu gehören korrekt verschachtelte Tags und Attributwerte in Anführungszeichen. Verschachtelte Elemente werden in der passenden Reihenfolge geschlossen.

Valide bedeutet, dass das Dokument zusätzlich die Regeln der jeweiligen Sprache erfüllt, beispielsweise die Vorgaben zu erlaubten Elementen und Pflichtattributen.

Ein valides XML-Dokument ist immer auch wohlgeformt. Ein syntaktisch korrekt geschriebenes Element mit einem selbst ausgedachten Namen kann gegen die vorgegebenen Regeln verstoßen. Prüfprogramme können solche Fehler erkennen und dir Hinweise geben.

Semantisches Markup und Barrierefreiheit

Mit HTML5 kamen zusätzliche Elemente hinzu, die Inhalte genauer beschreiben. Dazu gehören beispielsweise header und footer sowie figure für Abbildungen. Bei einem allgemeinen div vermittelt ein CSS-Klassenname diese Bedeutung den verarbeitenden Programmen nicht automatisch.

Ich achte bei den HTML-Dokumenten meiner IT-Azubis darauf, dass die gewählten Elemente zum Inhalt passen:

Überschriften erhalten passende Überschriftenelemente.

Für Aufzählungen stehen ul und li zur Verfügung.

Absätze werden mit p ausgezeichnet.

Kopf- und Fußbereiche erhalten die entsprechenden semantischen Elemente.

Abbildungen können mit figure umschlossen werden.

Suchmaschinen können durch semantisches Markup erkennen, welche Rolle ein Inhalt hat. Für Screenreader, die blinden Menschen Webseiten vorlesen, sind solche Angaben ebenfalls relevant: Sie können Überschriften entsprechend behandeln und Inhalte verständlicher wiedergeben. Wenn du deine Website entwickelst, solltest du auch Besucher:innen berücksichtigen, die eingeschränkt sehen oder eine Maus schwer bedienen können.

Begleitmaterial und weitere Themen

Unter anwendungsentwicklerpodcast.de/33 findest du die erwähnten Links und kannst mir Fragen oder Hinweise als Kommentar schicken. Per E-Mail erreichst du mich unter [email protected].

Auf meiner Website stelle ich außerdem einen Ausbildungsplan für Fachinformatiker:innen Anwendungsentwicklung als Excel-Datei bereit. Damit lassen sich Ausbildungsinhalte zeitlich zuordnen und verschieben....

In der zweiunddreißigsten Episode des Anwendungsentwickler-Podcasts gehe ich einige Fragen aus meiner Lernzielkontrolle zum Thema Zeichensätze und -kodierung durch.

TL;DR

Aus meinen Lernzielkontrollen greife ich Grundlagen zu Zeichensätzen und Zeichenkodierung auf, die du als Fachinformatiker:in für Anwendungsentwicklung kennen solltest. Ein Zeichensatz legt fest, welche Zeichen verfügbar sind; eine Zeichenkodierung beschreibt, wie sie als Bit- oder Bytefolgen gespeichert werden. Mit ASCII, ISO 8859-1 und Unicode samt UTF-8 kannst du nachvollziehen, wie Texte gespeichert werden und weshalb falsch gelesene Dateien Fragezeichen oder merkwürdige Sonderzeichen zeigen. Beim Austausch von Textdateien zwischen Windows und Linux musst du außerdem beachten, wie die Systeme Zeilenumbrüche speichern.

Kapitelmarken

[00:00:20] Lernzielkontrollen als neue Podcast-Reihe

[00:02:06] Bedeutung für Ausbildung und Fachgespräch

[00:03:30] Zeichensätze und Zeichenkodierung

[00:06:40] ASCII und seine 128 Zeichen

[00:07:41] Zeilenumbrüche unter Windows und Linux

[00:09:25] Ursprung von Carriage Return und Line Feed

[00:10:52] Acht-Bit-Zeichensätze und ISO 8859-1

[00:13:35] ANSI und ASCII

[00:14:25] Unicode als weltweiter Zeichenvorrat

[00:16:15] UTF-8 und mehrbyteige Zeichen

[00:18:57] Fragezeichen durch falsch gelesenes ISO

[00:20:40] Falsch dargestellte Zeichen durch falsch gelesenes UTF-8

[00:21:59] Kodierungsfehler selbst nachstellen

[00:22:53] BOM als Kennzeichnung am Dateianfang

[00:23:42] Rückblick auf die fachlichen Inhalte

[00:25:16] Weitere Lernzielkontrollen und Ausblick auf HTML und CSS

[00:25:45] Feedback und Kontakt

[00:26:23] Newsletter und Checklisten zum Abschlussprojekt

Inhalt

Zeichensatz vs. Zeichencodierung

ASCII: 7 Bit, lateinische Buchstaben, Zahlen usw.

Wichtige Sonderzeichen: Line Feed (\n, Position 10), Carriage Return (\r, Position 13)

Windows-Zeilenumbrüche: \r\n, Linux: \n

zusätzliches Bit -> ISO 8859

ANSI vs. ASCII

Unicode vs. UTF-8

Häufige Fehler

Sonderzeichen werden als Fragezeichen dargestellt: Text ist in ISO 8859 codiert, wird aber als UTF-8 interpretiert

Sonderzeichen werden als zwei andere Zeichen dargestellt: Text ist in UTF-8 codiert, wird aber als ISO 8859 interpretiert

Literaturempfehlungen

*(direkt beim Rheinwerk-Verlag bestellen*)

Das passende Kapitel im OpenBook: 16 Weitere Datei- und Datenformate - Rheinwerk Computing :: IT-Handbuch für Fachinformatiker

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Zeichensatz – Wikipedia

Zeichenkodierung – Wikipedia

American National Standards Institute – Wikipedia

American Standard Code for Information Interchange – Wikipedia

ISO 8859 – Wikipedia

ISO 8859-1 – Wikipedia

UTF-8 – Wikipedia

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) - Joel on Software

Character Encodings For Modern Programmers

Eine ausführliche Betrachtung der Historie von Zeichensätzen: RFCE013: ASCII

Zusammenfassung

Wissen aus meinen Lernzielkontrollen

Wenn ich meine IT-Azubis mündlich zu gerade behandelten Ausbildungsinhalten befrage, können sie ihr Wissen wiederholen und festigen. Die Reihe LZK, kurz für Lernzielkontrolle, greift solche Themen auf. Für dich als Fachinformatiker:in für Anwendungsentwicklung gehört Zeichenkodierung zum Grundwissen. Ob ich dazu im Fachgespräch Fragen stelle, hängt auch von deinem Abschlussprojekt ab, etwa wenn du Dateien zwischen Windows und Linux konvertierst.

Zeichensatz und Zeichenkodierung

Wenn du Texte darstellen möchtest, bestimmt der Zeichensatz, welche Zeichen dir zur Verfügung stehen. Dazu gehören Buchstaben und Ziffern sowie Zeichen, die den Text steuern, etwa Tabulatoren oder Zeilenumbrüche. Je mehr Sprachen du abbilden möchtest, desto größer muss dieser Zeichenvorrat sein. Deutsche Texte brauchen beispielsweise Umlaute und ß; andere Sprachen verwenden eigene Schriftzeichen.

Damit ein Computer diese Zeichen verarbeiten kann, ordnet die Zeichenkodierung ihnen Bit- oder Bytefolgen zu. Du kannst dir diese Zuordnung als Tabelle vorstellen, in der zu einem Code das passende Zeichen steht. Beim Lesen einer Datei entscheidet die gewählte Kodierung darüber, welche Zeichen aus den gespeicherten Bytes entstehen.

ASCII

Aus den 1960er-Jahren stammt ASCII, ausgeschrieben American Standard Code for Information Interchange. ASCII beschreibt einen Zeichensatz samt Kodierung und arbeitet mit sieben Bit. Damit lassen sich 128 Zeichen darstellen.

Enthalten sind die lateinischen Groß- und Kleinbuchstaben sowie die Ziffern von 0 bis 9. Hinzu kommen Sonder- und Steuerzeichen. Für Textdateien war ASCII lange verbreitet.

Zeilenumbrüche unter Windows und Linux

Wenn du Textdateien systemübergreifend erzeugst oder einliest, musst du die jeweiligen Zeilenumbrüche berücksichtigen:

Windows: Carriage Return und Line Feed bilden gemeinsam den Zeilenumbruch, abgekürzt CRLF. In vielen Programmiersprachen schreibst du dafür \r\n.

Linux: Ein Line Feed genügt als Zeilenumbruch und wird häufig als \n geschrieben.

Die beiden Steuerzeichen stehen an festen Positionen in der ASCII-Tabelle. Line Feed hat den Wert 10, während Carriage Return den Wert 13 hat. Der Backslash kennzeichnet in vielen Programmiersprachen eine Escape-Sequenz, durch die ein Zeichen eine besondere Bedeutung erhält.

Von der Schreibmaschine stammen die Bezeichnungen: Beim Carriage Return kehrt der Wagen an den Zeilenanfang zurück. Ein Line Feed schiebt das Papier um eine Zeile weiter. Erkennt ein Editor die Zeilenumbrüche einer Datei anders als vorgesehen, können Zeilen zusammenlaufen oder zusätzliche Umbrüche erscheinen.

Acht-Bit-Zeichensätze und ISO 8859-1

Für deutsche Texte fehlen in ASCII die Umlaute und das ß. Durch ein zusätzliches Bit entstehen 256 mögliche Werte, sodass weitere 128 Positionen für zusätzliche Zeichen verfügbar sind.

Weil auch dieser Platz für die verschiedenen Sprachen begrenzt ist, entstanden mehrere regionale Zeichensätze. Ihre zusätzlichen Positionen können unterschiedlich belegt sein. Wenn du eine Datei mit einer anderen Kodierung öffnest, erscheint deshalb unter Umständen ein anderes Zeichen als vorgesehen.

Für Westeuropa ist ISO 8859-1 relevant, das unter anderem deutsche Umlaute und ß enthält. Weitere Varianten der ISO-8859-Reihe decken andere Sprachräume ab. Beim Öffnen einer Textdatei brauchst du deshalb die Information, mit welcher Kodierung sie gespeichert wurde.

ANSI

Hinter ANSI steht das American National Standards Institute, eine Organisation, die Standards festlegt und mit dem Deutschen Institut für Normung vergleichbar ist. Im Sprachgebrauch wird ihr Name häufig im Zusammenhang mit ASCII verwendet. ASCII bezeichnet den konkreten Zeichensatz samt Kodierung.

Unicode und UTF-8

Um Schriftzeichen weltweit gemeinsam abzubilden, verfolgt Unicode das Ziel eines umfassenden Zeichenvorrats. Darin finden auch historische Schriften wie ägyptische Hieroglyphen Platz. Mit sieben oder acht Bit lässt sich ein so großer Vorrat an Zeichen kaum abbilden. Schon für 65.536 mögliche Werte brauchst du 16 Bit, was bei einer festen Breite von zwei Byte den Speicherbedarf gegenüber einem Byte pro Zeichen verdoppelt.

Mit UTF-8 lassen sich Unicode-Zeichen speichern, wobei ASCII-Zeichen weiterhin jeweils ein Byte belegen. Zeichen außerhalb von ASCII werden mit mehreren Bytes kodiert. Dadurch bleiben reine ASCII-Texte in derselben Form lesbar und behalten ihre bisherige Größe.

Die Abkürzung steht für UCS Transformation Format; UCS bedeutet Universal Character Set. Beim Lesen muss ein Programm erkennen, welche Bytes zusammen ein Zeichen bilden.

Typische Fehler beim Lesen von Texten

Anhand zweier Beispiele aus der täglichen Arbeit kannst du erkennen, was eine falsch gewählte Kodierung bewirkt:

Ein ISO-kodierter Text wird als UTF-8 gelesen: Ein Umlaut belegt in ISO 8859-1 ein Byte. Wenn das Programm dieses Byte als Beginn einer UTF-8-Folge liest und keine passende Fortsetzung findet, kann ein Fragezeichen als Ersatz erscheinen.

Ein UTF-8-Text wird als ISO gelesen: Die Bytes eines Umlauts werden einzeln als Zeichen interpretiert. Dadurch erscheinen an seiner Stelle zwei merkwürdige Zeichen.

Wenn du das selbst ausprobieren möchtest, kannst du in einem geeigneten Editor wie Notepad++ oder PSPad einen Text mit Umlauten speichern und anschließend mit einer anderen Kodierung lesen. So lässt sich beobachten, wie dieselben Bytes unterschiedlich dargestellt werden.

BOM am Dateianfang

Über eine besondere Bytefolge am Anfang einer Datei, die BOM, kann ein Programm Hinweise auf die verwendete Unicode-Kodierung erhalten. Bei UTF-8 kann diese Kennzeichnung helfen, die Datei passend zu lesen.

Weitere Themen aus der Ausbildung

Begleitend zur Ausbildung meiner IT-Azubis möchte ich weitere Inhalte aus den Lernzielkontrollen aufgreifen. Als nächstes Thema sind HTML und CSS vorgesehen, in deren Zusammenhang auch Zeichenkodierung behandelt wurde.

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[0:01] Herzlich willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:10] In dieser Episode geht es um Zeichen, Sätze und Kodierung. Viel Spaß!

[0:20] Hallo und herzlich willkommen zur 32. Episode des Anwendungsentwickler-Podcasts.

[0:26] Mein Name ist Stefan Macke und heute probiere ich mal was ganz Neues aus.

[0:31] Und zwar mache ich mit meinen Azubis regelmäßig sogenannte Lernzielkontrollen, wo ich sie nochmal mündlich abfrage zu bestimmten Ausbildungsinhalten, die sie gerade so gelernt haben.

[0:41] Und in dieser Episode werde ich mal so ein paar Fragen der zum jetzigen Zeitpunkt aktuellen Lernzielkontrolle durchgehen, und zwar rund um die Themen Zeichenkodierung und Zeichensätze.

[0:53] Da hatte ich vor, ich glaube, zwei Wochen auch meine Links der Woche zu gepostet, zu zwei sehr lesenswerten Artikeln rund um dieses Thema.

[1:01] Und aktuell habe ich meine beiden Azubis zu diesem Themenb

In der einunddreißigsten Episode des Anwendungsentwickler-Podcasts gebe ich Tipps für ein professionelles Layout der Projektdokumentation.

TL;DR

Aus meiner Arbeit als Prüfer bringe ich dir Tipps mit, mit denen du deine Projektdokumentation übersichtlich und gut lesbar gestaltest. Halte dich an die Vorgaben deiner IHK, nummeriere den Fließtext ab Seite 1 und arbeite mit einheitlichen Formatvorlagen sowie einer flachen Gliederung. Für Diagramme empfehle ich skalierbare Grafiken; Quelltext sollte in nichtproportionaler Schrift gesetzt sein. Artefakte gehören vorzugsweise in den Anhang und brauchen jeweils eine Beschriftung sowie einen Verweis im Text.

Kapitelmarken

[00:00:00] Einstieg und Thema der Episode

[00:01:18] Seitenstil und Seitennummerierung

[00:04:10] Leerraum und Seitenumbrüche

[00:05:15] Gliederungsebenen und Projektphasen

[00:06:32] Absatzkontrolle und Überschriften am Seitenende

[00:07:54] Abstand zwischen Absätzen

[00:08:44] Formatvorgaben deiner IHK

[00:09:42] Einheitliche Schriftarten und Serifenschriften

[00:11:18] Blocksatz und Silbentrennung

[00:12:34] Hervorhebungen sparsam einsetzen

[00:13:35] Einheitlich formatieren

[00:15:04] Semantische Befehle und Formatvorlagen

[00:17:01] Nichtproportionale Schrift für technische Begriffe

[00:18:15] Anführungszeichen richtig einsetzen

[00:19:18] Artefakte im Anhang platzieren

[00:20:04] Artefakte beschriften und im Text referenzieren

[00:21:38] Skalierbare Grafiken und lesbare Diagramme

[00:23:33] Quelltext formatieren und hervorheben

[00:24:32] Quelltext direkt einbinden mit LaTeX

[00:25:46] Aussagekräftige Codeausschnitte und zugeschnittene Screenshots

[00:27:18] Typografische Details bei Bindestrichen und Gedankenstrichen

[00:28:17] Feedback und Fragen zur Ausbildung

[00:29:08] Newsletter und Checkliste zur Projektdokumentation

Inhalt

Seitenstil

Seiten korrekt durchnummerieren.

Keinen unnötigen Leerraum lassen.

Maximal drei Gliederungsebenen verwenden.

Hurenkinder und Schusterjungen entfernen.

Absätze deutlich voneinander absetzen (z.B. mit vertikalem Abstand).

Text

Auf die Vorgaben der IHK achten (Schriftgröße, Seitenzahl).

Einheitliche Schriftart nutzen.

Serifenschrift für den Fließtext verwenden.

Blocksatz verwenden.

Silbentrennung aktivieren.

Sparsam mit Hervorhebungsmitteln umgehen.

Technische Begriffe in nicht-proportionaler Schrift setzen.

Text nicht mit Anführungszeichen hervorheben.

Artefakte

Große Artefakte immer in den Anhang verschieben.

Alle Artefakte beschriften und im Text referenzieren.

Grafiken müssen gut lesbar sein.

Skalierbare Grafikformate verwenden.

Quelltext highlighten.

Nur interessante Ausschnitte aus Screenshots zeigen.

Literaturempfehlungen

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Hurenkind und Schusterjunge – Wikipedia

Vektorgrafik – Wikipedia

Serife – Wikipedia

Vorlage für die Projektdokumentation

Einführung in LaTeX: 00. Einleitung

Weitere Infos zur ProjektdokumentationDu suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.Jetzt anmelden!

Zusammenfassung

Vorgaben deiner IHK und Seitenzahlen

Als Prüfer achte ich darauf, ob du den erlaubten Umfang einhältst. Bei meiner IHK umfasst die Projektdokumentation höchstens 15 Seiten Fließtext und 25 Seiten Anhang. Verzeichnisse, Deckblatt und die Erklärung zählen dabei zusätzlich. Für deine Arbeit gelten die Vorgaben deiner eigenen IHK, auch bei Schriftart, Schriftgröße und Position der Seitenzahlen. Formfehler können zu Punktabzug führen.

Beginne den Fließtext mit der Seitenzahl 1 auf der ersten Seite der Einleitung und nummeriere ihn mit arabischen Ziffern durch. So lässt sich sein Umfang direkt erkennen. Für die Seiten davor empfehle ich große römische Ziffern, für den Anhang kleine römische Ziffern.

Platziere die Seitenzahlen durchgehend an derselben Stelle, beispielsweise unten rechts oder unten mittig. Beim Durchblättern sollen sich Seiten und Verweise schnell finden lassen.

Beim Prüfen zähle ich auch den Platz, den dein Text tatsächlich einnimmt. Größere Artefakte und umfangreiche leere Bereiche ziehe ich dafür vom Seitenumfang ab.

Seiten sinnvoll füllen und Kapitel gliedern

Lass Kapitel innerhalb der kurzen Dokumentation mit etwas Abstand aufeinander folgen. Seitenumbrüche vor jeder Kapitelüberschrift erzeugen schnell mehrere Seiten Leerraum, wodurch Platz für deine Inhalte verloren geht. Das kann sich auf die Note auswirken.

Ich empfehle dir höchstens zwei Gliederungsebenen; die dritte Ebene bildet für mich die Obergrenze. Bei 15 Seiten führen tiefere Ebenen zu sehr kurzen Unterkapiteln. Orientiere die Kapitel an den Projektphasen, die du durchlaufen hast.

Halte zusammengehörige Absätze beim Seitenwechsel möglichst zusammen. Eine letzte Absatzzeile allein auf der Folgeseite heißt im Textsatz "Hurenkind". Steht nur die erste Zeile eines Absatzes am Ende einer Seite, spricht man von einem "Schusterjungen". Word bietet dafür eine automatische Absatzkontrolle; in LaTeX lässt sich das entsprechend einstellen.

Sorge dafür, dass eine Überschrift zusammen mit dem zugehörigen Text auf derselben Seite beginnt.

Trenne Absätze durch einen sichtbaren vertikalen Abstand, damit einzelne Gedankengänge erkennbar bleiben. In LaTeX lässt sich das über die passende Klasse beziehungsweise deren Einstellungen festlegen.

Schrift und Fließtext gestalten

Halte dein Schriftbild einheitlich. Für den Fließtext empfehle ich eine Serifenschrift, etwa Times New Roman. Serifen sind kleine Ansätze an den Buchstaben, die das Auge beim Lesen entlang der Zeile führen sollen. Arial ist eine serifenlose Schrift. Prüfe auch die voreingestellten Schriftarten deiner Textverarbeitung.

Setze den Fließtext nach meiner Empfehlung in Blocksatz mit aktivierter Silbentrennung. Durch die Silbentrennung lassen sich große Lücken zwischen Wörtern vermeiden, die beim Blocksatz entstehen können.

Hebe Begriffe sparsam mit Fett- oder Kursivschrift hervor. Unterstrichene Wörter wirken heute häufig wie Links. Zusätzliche Leerzeichen zwischen einzelnen Buchstaben erschweren der Textverarbeitung, ein Wort zu erkennen.

Berücksichtige, dass Prüfer:innen deine Dokumentation möglicherweise schwarz-weiß ausdrucken. Farbige Hervorhebungen können dabei ihren Zweck verlieren.

Begriffe einheitlich formatieren

Lege fest, wie du bestimmte Arten von Begriffen darstellst, und halte diese Regeln im gesamten Text ein. Wenn Fachbegriffe kursiv erscheinen, sollten alle entsprechenden Begriffe so gesetzt sein. Abweichungen lassen mich beim Prüfen nach einer Bedeutung suchen und können als unsauber gearbeitet auffallen.

Arbeite mit semantischen Befehlen oder Formatvorlagen. In LaTeX kannst du eigene Befehle etwa für Klassennamen und Entitäten anlegen. Word bietet dafür Textformatvorlagen. Damit änderst du die Darstellung einer Begriffskategorie zentral.

Für Code und technische Bezeichner empfehle ich nichtproportionale Schrift. Dabei hat jedes Zeichen dieselbe Breite, wodurch Einrückungen und untereinanderstehende Zeichen erhalten bleiben. Auch Kommandozeilenbefehle lassen sich so kennzeichnen.

Verwende Formatvorlagen, wenn du Begriffe hervorheben möchtest. Anführungszeichen sind eingegebene Textzeichen und müssen bei einem späteren Wechsel der Darstellung einzeln entfernt werden. Wo Anführungszeichen sprachlich erforderlich sind, gehören in einen deutschen Text die typografisch passenden Zeichen: "…".

Artefakte in den Anhang aufnehmen

Ich empfehle dir, Artefakte grundsätzlich im Anhang unterzubringen. Alles, was größer als eine halbe Seite ist, gehört nach meiner Regel dorthin. Im genannten Beispiel stehen 15 Textseiten zur Verfügung, um ein 70-stündiges Projekt zu dokumentieren. Große Abbildungen und Tabellen nehmen davon viel Platz ein.

Gib jedem Artefakt eine aussagekräftige Beschriftung und eine fortlaufende Nummer. Dazu gehört das passende Verzeichnis, beispielsweise ein Abbildungs- oder Tabellenverzeichnis.

Verweise im Fließtext ausdrücklich auf jedes Artefakt, etwa mit "wie im ER-Modell in Abbildung 7 zu sehen ist". Dadurch erhält es einen nachvollziehbaren Bezug zu deinem Projekt. Artefakte ohne Bezug zum Text führen bei mir zu Punktabzug.

Diagramme lesbar exportieren

Exportiere Diagramme möglichst als Vektorgrafiken, beispielsweise im SVG- oder EPS-Format. Sie bleiben beim Vergrößern im PDF und beim Drucken scharf.

Prüfe die Größe der Schrift innerhalb deiner Diagramme. Auch Beschriftungen in ER-Modellen und Klassendiagrammen müssen lesbar sein, damit ich die Inhalte bewerten kann.

Rastergrafiken wie JPEG, PNG oder GIF werden beim Vergrößern pixelig. Das gilt ebenfalls für Screenshots.

Quelltext und Screenshots auswählen

Setze Quelltext in nichtproportionaler Schrift mit nachvollziehbaren Einrückungen. Syntax-Highlighting erleichtert das Lesen; dafür sind auch Farben oder weitere Hervorhebungen möglich.

Lass deine Textverarbeitung den Quelltext direkt darstellen. Das LaTeX-Paket listings unterstützt anpassbare Hervorhebungen und Zeilennummern. Außerdem kannst du ausgewählte Zeilen unmittelbar aus einer Quellcodedatei einbinden.

Wähle Codeausschnitte, die interessante Teile deiner Arbeit zeigen. Seiten voller Getter und Setter beanspruchen Platz, ohne viel über dein Projekt zu vermitteln.

Schneide Screenshots auf den relevanten Bereich zu. Zeige beispielsweise das Programmfenster, damit dein:e Prüfer:in die Oberfläche ausreichend groß erkennen kann. Desktop und Hintergrundfenster nehmen zusätzlichen Platz ein.

Typografische Details und meine Checkliste

Ich achte beim Prüfen auch auf typografische Details. Ein Bindestrich ist kürzer als ein Gedankenstrich; LaTeX stellt

In der dreißigsten Episode des Anwendungsentwickler-Podcasts beende ich meine Reihe rund um die Inhalte der Projektdokumentation.

TL;DR

Ich zeige dir, welche Inhalte nach der Implementierungsphase in deine Projektdokumentation gehören und wie du den abschließenden Teil aufbaust. Du hältst fest, wie dein:e Kund:in die Software abnimmt und wie sie bei den Anwender:innen ankommt; außerdem erstellst du passende Handbücher für Anwender:innen und Entwickler:innen. Im Fazit vergleichst du die geplanten mit den tatsächlich benötigten Zeiten und beschreibst, wie dein Projekt weitergeht. Übernommene Inhalte belegst du mit Quellen, während du größere Artefakte im Anhang unterbringst und branchenspezifische Begriffe bei Bedarf in einem Glossar erläuterst.

Kapitelmarken

[00:00:00] Einstieg und Thema der Episode

[00:01:47] Software abnehmen lassen und das Verfahren dokumentieren

[00:03:16] Software bereitstellen und Wartezeiten einplanen

[00:05:33] Handbücher für Anwender:innen und Entwickler:innen erstellen

[00:09:00] Fazit: Geplante und tatsächliche Projektzeiten vergleichen

[00:11:40] Lessons Learned und Zukunft des Projekts

[00:13:18] Fließtext und ergänzende Teile der Dokumentation

[00:14:20] Quellen zitieren und ein Literaturverzeichnis erstellen

[00:17:18] Branchenspezifische Begriffe im Glossar erläutern

[00:20:10] Eidesstattliche Erklärung und IHK-Formblätter

[00:21:28] Größere Artefakte im Anhang unterbringen

[00:22:59] Wie Bilder und Leerflächen den bewerteten Textumfang beeinflussen

[00:24:48] Sorgfalt bei der Projektdokumentation und eigene Verantwortung

[00:26:18] Feedback, Vorlagen und Kontaktmöglichkeiten

[00:27:48] Newsletter und Checklisten für die Projektarbeit

Inhalt

Abnahme und Einführung

Dokumentation

Kunden-/Entwicklerdokumentation

Fazit

Soll-/Ist-Vergleich

Ausblick

Literaturverzeichnis

Glossar

eidesstattliche Erklärung

Anhang

ggfs. nur Auszüge anhängen

Literaturempfehlungen

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Vorlage für die Projektdokumentation

Einführung in LaTeX: 00. Einleitung

Weitere Infos zur ProjektdokumentationDu suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.Jetzt anmelden!

Zusammenfassung

Wie du die Software abnehmen lässt

Nach dem Programmieren folgen weitere Aufgaben, bevor die Software eingesetzt werden kann. Für deine Projektdokumentation hältst du fest, wie du dabei vorgehst.

Richte dich danach, wie dein Betrieb Software abnimmt. Je nach Unternehmen prüft der Fachbereich die Anwendung oder dein:e Kund:in bestätigt mit einem unterschriebenen Abnahmeprotokoll, dass die Funktionen geprüft wurden.

Wenn dein Betrieb ein formelles Verfahren vorgibt, hältst du es auch bei deinem Abschlussprojekt ein. Vorgaben zur Qualität oder Sicherheit können dabei eine Rolle spielen.

Ein unterschriebenes Abnahmeprotokoll kannst du als Beleg in den Anhang aufnehmen. Dafür reichen auch passende Auszüge.

Wie die Anwendung bei den Anwender:innen ankommt

Beschreibe kurz, wie du deine Software bereitstellst. Bei einer Webanwendung hältst du beispielsweise fest, wie sie auf den Webserver gelangt und wie die Anwender:innen die Adresse erhalten. Eine Desktopanwendung muss auf die vorgesehenen Rechner verteilt werden.

Bei einer App können zusätzliche Schritte nötig sein, um sie in einem App-Store zu veröffentlichen. Anbieter prüfen eingereichte Apps teilweise vorab, wodurch Wartezeiten entstehen. Wenn solche Abläufe schon zu Beginn bekannt sind, berücksichtigst du sie in deinem Projektplan.

Was du für Anwender:innen und Entwickler:innen dokumentierst

Zur Projektarbeit gehören auch Unterlagen für die Menschen, die später mit der Anwendung arbeiten oder ihren Code pflegen. Die Ausbildungsordnung fordert, dass du dein Projekt kundenspezifisch dokumentieren kannst. In Bewertungsschemata gibt es dafür einen eigenen Punkt.

Ein Handbuch für Anwender:innen

Beschreibe, wie die zentralen Anwendungsfälle ablaufen.

Ergänze Screenshots, wenn sie beim Verstehen helfen. Das Handbuch darf auch farbig gestaltet sein.

Wähle eine Form, die zu deinem Projekt und deinen Anwender:innen passt.

Unterlagen für Entwickler:innen

Bereits erstellte Artefakte, etwa ein Klassendiagramm, können helfen, den Code verständlich zu beschreiben.

Aus Kommentaren im Quellcode lassen sich beispielsweise mit Javadoc HTML-Seiten erzeugen, auf denen Klassen und ihre Methoden beschrieben werden.

Kommentiere deinen Code während des Programmierens. Für das anschließende Erzeugen der HTML-Seiten plane ich etwa eine halbe Stunde ein; eine solche Dokumentation reicht für viele Projekte aus.

Wie du dein Fazit schreibst

Geplante und tatsächliche Zeiten vergleichen

Mit einer Tabelle zeigst du für jede Projektphase, wie viele Stunden du eingeplant und wie viele du gebraucht hast. Anschließend vergleichst du die Summen und begründest, weshalb sich Zeiten verschoben haben.

Im hier beschriebenen Prüfungsrahmen beträgt die Projektzeit 70 Stunden. Einzelne Phasen können davon abweichen, etwa wenn du die Analyse schneller abschließt und mehr Zeit für Tests brauchst. Bei einem kleinen Projekt machen schon wenige Stunden einen merklichen Anteil aus. Größere Abweichungen lassen Fragen dazu entstehen, wie genau du den Aufwand eingeschätzt hast.

Beschreiben, wie dein Projekt weitergeht

Halte fest, welche Aufgaben nach der Prüfung folgen. Dazu können zusätzliche Wünsche deiner Kund:innen gehören oder die Frage, wer die Anwendung künftig pflegt. Wenn du nach der Prüfung selbst weiter daran arbeitest, beschreibst du diese Perspektive ebenfalls.

Optional kannst du persönliche Lessons Learned ergänzen: Was hast du beim Projekt gelernt, und welche Erfahrungen hast du mit dem Vorgehen gemacht? Damit bekommt deine Arbeit eine persönliche Note.

Welche Teile nach dem Fazit folgen

Bei der IHK, für die ich tätig bin, sind 15 Seiten Fließtext vorgesehen. Das Fazit endet damit auf Seite 15. Deckblatt und vorangestellte Verzeichnisse zählen dort ebenso wenig zum Fließtext wie die nachfolgenden Teile.

Quellen belegen

Führe übernommene Inhalte im Literaturverzeichnis auf. Als Quellen kommen beispielsweise gelesene Dokumentationen oder Webseiten infrage, ebenso Bücher und Gespräche mit deinem/deiner Ausbilder:in.

Setze direkt an der betreffenden Textstelle einen Quellenhinweis, etwa als Fußnote. So lässt sich nachvollziehen, woher ein Inhalt stammt und welchen Anteil du selbst erarbeitet hast.

Sortiere das Literaturverzeichnis und gib die Angaben an, die zur jeweiligen Quelle gehören, darunter Autor:in und Erscheinungsjahr sowie Titel und Publikation.

LaTeX kann aus BibTeX-Einträgen ein Literaturverzeichnis erzeugen. Auch Word bietet Funktionen, mit denen du Quellen im Text referenzierst.

Wenn erkennbare Quellen fehlen oder übernommene Inhalte ohne Beleg bleiben, ziehe ich bei der Bewertung Punkte ab.

Fachbegriffe erläutern

Ein Abkürzungsverzeichnis führt Kürzel mit ihrer ausgeschriebenen Bedeutung auf, beispielsweise GUI für Graphical User Interface. In einem Glossar erläuterst du Fachbegriffe mit einigen Sätzen.

Ein Glossar bietet sich an, wenn dein Projekt viele branchenspezifische Begriffe enthält. Prüfer:innen bringen IT-Fachwissen mit, kennen aber die Besonderheiten deiner Branche möglicherweise kaum. Auch SAP-interne Begriffe brauchen deshalb eine verständliche Erklärung. Allgemein bekannte IT-Begriffe kannst du als bekannt voraussetzen.

Die geforderte Erklärung beifügen

Manche IHKs verlangen eine eidesstattliche Erklärung oder stellen dafür ein Formblatt bereit. Darin bestätigst du beispielsweise, dass du die Prüfungsleistung selbst erbracht und sie bisher bei keinem anderen Prüfungsausschuss eingereicht hast. Übernommene Inhalte müssen entsprechend gekennzeichnet sein. Falls deine IHK eine solche Erklärung fordert, unterschreibst du sie und fügst sie nach deren Vorgaben bei.

Was in den Anhang gehört

Meine Faustregel lautet: Artefakte, die mehr als eine halbe Seite beanspruchen, kommen in den Anhang. Dazu gehören größere Tabellen oder Diagramme, ebenso Quelltextausschnitte und Auszüge aus dem Pflichtenheft. Im Fließtext können kleinere Tabellen stehen.

Den begrenzten Platz brauchst du, um dein Projekt verständlich zu beschreiben. Bei meiner Bewertung ziehe ich größere Bilder und Tabellen im Fließtext vom tatsächlichen Textumfang ab; das gilt auch für größere leere Flächen. Wenn dadurch deutlich weniger Text übrig bleibt, wirkt sich das auf die Note aus.

Wo du meine ergänzenden Materialien findest

Unter anwendungsentwicklerpodcast.de findest du die Shownotes mit einem Link zu meiner Vorlage für die Projektdokumentation und weiteren Quellen. Über die Kommentare kannst du mir zusätzliche Inhalte nennen, die bei deinem Projekt eine Rolle spielen. Fragen kannst du auch per Mail an [email protected] oder über das Kontaktformular stellen.

Wenn du dich unter anwendungsentwicklerpodcast.de/newsletter anmeldest, erhältst du Zugriff auf meine Checklisten. Sie decken den Projektantrag ab und helfen dir außerdem, deine Projektdokumentation sowie die Projektpräsentation vor dem Abgeben zu prüfen.

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[0:00] Hi, hier ist Stefan. In dieser Podcast-Episode geht es um die Projektdokumentation. Wenn

[0:05] du dazu noch mehr Informationen von mir haben willst, dann schau doch mal auf meiner Website

[0:08] vorbei unter dieperfekteprojektdokumentation.de. Und jetzt viel Spaß mit der Podcast-Episode.

[0:18] Herzlich willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker

...

In der neunundzwanzigsten Episode des Anwendungsentwickler-Podcasts setze ich meine Podcast-Serie zu den Punkten einer sinnvollen Gliederung der Projektdokumentation fort.

TL;DR

Für deine Projektdokumentation als IT-Azubi empfehle ich dir, technische Entscheidungen anhand der Anforderungen zu begründen und mit passenden Modellen nachvollziehbar zu machen. In der Entwurfsphase entsteht das Pflichtenheft, das die gewählte Technik sowie den Aufbau deiner Anwendung beschreibt und bei Bedarf Oberflächenentwürfe enthält. Wie detailliert du vorab planst, hängt von deinem Entwicklungsprozess ab. Für die Implementierungsphase gehören aussagekräftige Klassendiagramme und ausgewählte Quelltextausschnitte mit den dazugehörigen Tests in die Dokumentation.

Kapitelmarken

[00:00:00] Einstieg und Hinweise zur Projektdokumentation

[00:00:33] Anschluss an Analysephase und Lastenheft

[00:01:22] Entwurfsphase und Pflichtenheft als Projektergebnis

[00:03:29] Die passende Plattform auswählen

[00:05:55] Technologien begründen und mit Nutzwertanalyse bewerten

[00:08:25] Architektur und Komponenten planen

[00:11:09] Das Datenmodell herleiten und dokumentieren

[00:13:49] Datenstrukturen außerhalb einer Datenbank darstellen

[00:14:28] Oberflächen entwerfen und mit dem/der Kund:in abstimmen

[00:17:17] Das Pflichtenheft zusammenstellen

[00:18:33] Entwurfstiefe und UML passend zum Entwicklungsprozess

[00:21:02] Inhalte der Implementierungsphase dokumentieren

[00:22:14] Testgetrieben entwickeln und Klassendiagramme erstellen

[00:23:42] Eigene Kernklassen im Klassendiagramm zeigen

[00:25:32] Diagramme und Entwicklungsprozess aufeinander abstimmen

[00:26:11] Zentrale Algorithmen mit UML darstellen

[00:28:14] Aussagekräftige Quelltextausschnitte auswählen

[00:30:01] Passende Tests als Dokumentation des Verhaltens

[00:31:44] Ausblick und Feedback

[00:32:43] Fragen und Kontaktmöglichkeiten

[00:33:04] Newsletter und Checklisten zur Abschlussprüfung

Inhalt

Entwurf

Plattform und Technologien

Komponenten und Architektur

Datenmodell

Mockups der GUI

Implementierung

Maßnahmen zur Qualitätssicherung

Literaturempfehlungen

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Vorlage für die Projektdokumentation

Einführung in LaTeX: 00. Einleitung

Weitere Infos zur ProjektdokumentationDu suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.Jetzt anmelden!

Zusammenfassung

Entwurfsphase und Pflichtenheft

Aus den fachlichen Anforderungen im Lastenheft entwickelst du einen technischen Entwurf. Dabei beschreibst du die Software so genau, dass ein:e andere:r Entwickler:in sie anhand deiner Unterlagen umsetzen kann.

Im Pflichtenheft hältst du fest, wie du die Anforderungen technisch erfüllen willst. Dazu gehören beispielsweise das Datenmodell und die Ablauflogik. Falls deine Anwendung eine grafische Oberfläche hat, kommen entsprechende Entwürfe hinzu.

Laut der im Podcast angesprochenen Berufsverordnung kann auch ein Abschlussprojekt vorgesehen sein, das mit dem fertigen Pflichtenheft endet. Damit zeigst du deine Fähigkeiten beim methodischen Entwerfen von Software.

Plane Zeit für das Pflichtenheft ein und füge zumindest Auszüge im Anhang deiner Projektdokumentation hinzu. In echten Projekten kann es zum Vertrag gehören und festlegen, welche Leistung du erbringen sollst.

Plattform und Technologien begründet auswählen

Ob deine Anwendung im Browser oder auf einem Mobilgerät laufen soll, ergibt sich aus den Anforderungen. Auch die vorgesehene Laufzeitumgebung beeinflusst deine Entscheidung.

Begründe, warum die gewählte Plattform zu deinem Projekt passt. Bei einer Webanwendung entfällt beispielsweise das Installieren auf den Clients, während du berücksichtigen musst, welche Browser unterstützt werden sollen. Für eine mobile Anwendung kann entscheidend sein, dass sie auch offline funktioniert.

Beschreibe anschließend die konkrete Technik, mit der du arbeiten willst. Erläutere etwa, warum du eine bestimmte Programmiersprache auswählst und welche Frameworks dazu passen. Auch das Betriebssystem gehört zu diesen technischen Entscheidungen.

Mit einer Nutzwertanalyse kannst du mögliche Technologien anhand projektbezogener Kriterien bewerten. Geeignete Kriterien ergeben sich beispielsweise daraus, ob du XML verarbeiten oder einen REST-Service bereitstellen musst.

Begründe auch Technik, die dein Betrieb bereits einsetzt, anhand ihrer Eignung für dein Projekt. Dadurch kann ein:e Prüfer:in nachvollziehen, wie du zu deiner Entscheidung gekommen bist.

Architektur und Komponenten planen

Bevor du einzelne Klassen ausarbeitest, legst du fest, wie deine Anwendung grob aufgebaut sein soll. Für ein überschaubares Abschlussprojekt empfehle ich dir, dich an etablierten Architekturen zu orientieren.

Ein UML-Komponentendiagramm zeigt die Bestandteile deiner Software und ihre Beziehungen. Bei MVC ordnest du dabei zu, welche Aufgaben zu den jeweiligen Architekturbestandteilen gehören.

Falls Teile deiner Software auf verschiedenen Systemen laufen, kannst du mit einem Verteilungsdiagramm darstellen, wo sie ausgeführt werden. Das betrifft etwa eine Serverkomponente und eine App auf einem Mobilgerät.

Berücksichtige beim Planen der Reihenfolge, welche Komponenten voneinander abhängen. Welche du zuerst entwickelst, richtet sich nach deinem Projekt.

Datenmodell verständlich dokumentieren

Bei datenbankgestützten Anwendungen bauen viele weitere Teile der Software auf dem Datenmodell auf. Deshalb räume ich diesem Bereich in der Dokumentation ausreichend Platz ein.

Wähle eine Darstellung, die zu deinen Daten passt, beispielsweise ein ER-Modell oder ein Tabellenmodell. Für eine Graphdatenbank kommt ein entsprechendes Graphmodell infrage.

Beschreibe, wie du das Modell aus den Anforderungen abgeleitet hast. Erläutere besondere Entscheidungen, etwa bewusst vorgesehene Redundanzen oder weshalb du etwas als eigene Entität modellierst.

Auch Daten aus Dateien brauchen eine verständliche Darstellung. Wenn deine Anwendung etwa JSON oder XML verarbeitet, dokumentierst du die jeweilige Struktur in einer dafür geeigneten Form.

Grafische Oberflächen mit dem/der Kund:in abstimmen

Wenn dein Projekt eine grafische Oberfläche enthält, erstellst du vorab Entwürfe und besprichst sie mit dem/der Kund:in. Änderungen lassen sich in dieser Phase mit geringerem Aufwand einarbeiten.

Mockups können auf Papier entstehen oder mit einer passenden Software erstellt werden. Auch PowerPoint oder Excel kommen dafür infrage.

Für einen gemeinsamen Papierentwurf kannst du einen Termin in deiner Projektplanung vorsehen. Die Skizze lässt sich anschließend einscannen und in die Dokumentation aufnehmen.

Hole anhand des Entwurfs Rückmeldungen ein, damit du die Oberfläche vor dem Programmieren abstimmen kannst.

Die Entwurfstiefe an deinen Prozess anpassen

Bei einem agilen Vorgehen empfehle ich dir, zunächst den groben Aufbau und die Datenstrukturen festzulegen sowie vorhandene Oberflächen zu entwerfen. Konkrete Details auf Methodenebene ergeben sich dann beim Entwickeln.

Wenn dein Prozess einen detaillierten Entwurf verlangt, ergänze passende UML-Diagramme. Ein Klassendiagramm beschreibt die konkreten Klassen, während beispielsweise ein Sequenzdiagramm ihre Zusammenarbeit sichtbar macht. Für solche Darstellungen empfehle ich UML; im Podcast werden auch Programmablaufpläne und Nassi-Shneiderman-Diagramme als Inhalte der schriftlichen Prüfung angesprochen.

Die Implementierungsphase nachvollziehbar zeigen

Da das Programmieren häufig den größten Zeitanteil im Projekt beansprucht, sollte dieser Bereich entsprechend Raum in deiner Dokumentation erhalten.

Für objektorientierte Software gehört für mich ein Klassendiagramm dazu. Du kannst es vorab entwerfen oder nachträglich aus deinem Quelltext erzeugen. Der Zeitpunkt muss zu dem Entwicklungsprozess passen, den du beschreibst.

Beim Test Driven Development entsteht die konkrete Struktur während des testgetriebenen Entwickelns. Anschließend kannst du sie dokumentieren.

Richte das Klassendiagramm auf deine selbst entwickelten Kernklassen und deren Logik aus. Beschränke dargestellte Framework-Bestandteile und automatisch erzeugte Methoden auf das, was zum Verständnis beiträgt.

Für einen zentralen Algorithmus kann ein zusätzliches UML-Diagramm sinnvoll sein. Ein Aktivitätsdiagramm stellt Abläufe dar; bei einem Zustandsautomaten eignet sich ein Zustandsdiagramm. Wähle solche zusätzlichen Darstellungen gezielt aus, da du sie bei Änderungen pflegen musst.

Quelltext und passende Tests auswählen

Mit ausgewählten Ausschnitten aus deinem eigenen Quelltext zeigst du, wie du programmiert hast. Dafür eignen sich Stellen mit aussagekräftiger Logik, beispielsweise der Umgang mit generischen Klassen oder Lambdas.

Begrenze die Ausschnitte auf Code, an dem sich deine eigene Leistung erkennen lässt. So bleibt Platz für die Modelle und das methodische Vorgehen.

Ergänze Testcode, der zu den gezeigten Quelltextausschnitten gehört. An den Tests lässt sich ablesen, wie sich die Software unter bestimmten Bedingungen verhalten soll.

Tests dienen zugleich als Dokumentation des Codes. Weil sie gemeinsam mit der Software weiterentwickelt und gepflegt werden, helfen sie dabei, das erwartete Verhalten nachzuvollziehen.

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[0:00] Hi, hier ist Stefan. In dieser Podcast-Episode geht es um die Projektdokumentation. Wenn

[0:05] du dazu noch mehr Informationen von mir haben willst, dann schau doch mal auf meiner Website

[0:08] vorbei unter dieperfekteprojektdokumentation.de....

In der achtundzwanzigsten Episode des Anwendungsentwickler-Podcasts führe ich die Punkte einer sinnvollen Gliederung der Projektdokumentation fort.

TL;DR

Ich zeige dir, wie du Projektplanung und Analysephase in deiner Projektdokumentation beschreibst. Du gliederst dein Projekt in überschaubare Aufgaben, begründest deinen Entwicklungsprozess und planst die benötigten Ressourcen samt Kosten ein. In der Analyse prüfst du, ob sich das Projekt wirtschaftlich lohnt, und recherchierst vorhandene Software für deine Make-or-Buy-Entscheidung. Ein Use-Case-Diagramm und schriftlich festgehaltene Anforderungen, etwa in einem Lastenheft, machen nachvollziehbar, was dein System leisten soll.

Kapitelmarken

[00:00:19] Gliederung der Projektdokumentation: Teil 2

[00:01:26] Projektplanung und Aufgaben eines/einer Projektleiter:in

[00:02:22] Projektphasen und Wasserfallmodell

[00:05:03] Zeitanteile der Projektphasen einschätzen

[00:06:00] Aufgaben im Zeitplan sinnvoll aufteilen

[00:08:00] Zeit und Iterationen bei agilen Prozessen planen

[00:09:15] Entwicklungsprozess beschreiben und begründen

[00:11:13] Ressourcen und Eh-da-Kosten berücksichtigen

[00:13:12] Projektablauf bei verschiedenen Vorgehensmodellen

[00:14:15] Analysephase und Wirtschaftlichkeit des Projekts

[00:15:51] Projektkosten und Arbeitszeit berechnen

[00:17:12] Einsparungen und Amortisation ermitteln

[00:18:02] Make-or-Buy-Entscheidung und Marktrecherche

[00:21:05] Funktionen mit einem Use-Case-Diagramm beschreiben

[00:22:49] Fachliche Anforderungen und Lastenheft

[00:23:42] Anforderungen als User Stories formulieren

[00:24:56] Anforderungen mit MoSCoW priorisieren

[00:26:41] Anforderungen überprüfbar dokumentieren

[00:27:45] Lastenheft erstellen und den Fachbereich unterstützen

[00:30:11] Vorlage, LaTeX-Kurs und Shownotes

[00:30:54] Feedback und Kontakt

[00:31:44] Newsletter und Checklisten zum Abschlussprojekt

Inhalt

Projektplanung

Projektphasen mit Zeitplanung

Entwicklungsprozess

Ressourcenplanung

Projektablauf

Analyse

Wirtschaftlichkeitsbetrachtung, Make or buy

Use-Cases

Lastenheft

Literaturempfehlungen

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Themenfindung für das Abschlussprojekt - Anwendungsentwickler-Podcast #24

Inhalte des Projektantrags - Anwendungsentwickler-Podcast #25

Vorlage für die Projektdokumentation

Einführung in LaTeX: 00. Einleitung

Weitere Infos zur ProjektdokumentationDu suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.Jetzt anmelden!

Zusammenfassung

Projektplanung in der Projektdokumentation

Ich setze die Gliederung nach der Einleitung mit der Projektplanung und der Analysephase fort. Als IT-Azubi zeigst du hier, wie du dein Abschlussprojekt als Fachinformatiker:in Anwendungsentwicklung methodisch angehst und praktisch umsetzt.

Projektphasen festlegen

Gliedere dein Projekt vor Beginn in Phasen, die zu deinem Entwicklungsprozess passen. Damit übernimmst du Aufgaben eines/einer Projektleiter:in, zu denen auch das Planen der Zeit und der benötigten Ressourcen gehört.

Beim Wasserfallmodell durchläuft dein Projekt üblicherweise Analyse, Entwurf, Implementierung, Test und Dokumentation. Diese Bereiche gehören auch in deine Projektdokumentation, damit dein Vorgehen und die entstandene Software nachvollziehbar werden.

Für das im Podcast betrachtete 70-Stunden-Projekt eignet sich das Wasserfallmodell durch seine klar abgegrenzten Phasen. Ich begegne diesem Modell in einem großen Teil der Dokumentationen, die ich als Prüfer lese.

Auch bei einem iterativen Vorgehen wie Scrum kommen Analyse, Entwurf und Test vor. Du durchläufst diese Schritte innerhalb der einzelnen Iterationen und planst vorab, welche Inhalte du darin bearbeiten möchtest.

Zeit für konkrete Aufgaben einplanen

Schätze, wie viel Zeit jede Phase braucht. Die Zeitanteile sollen zur Aufgabe passen und in einem sinnvollen Verhältnis stehen. Aus dem Plan lässt sich auch erkennen, welche technische Tiefe dein Projekt hat.

Teile umfangreiche Phasen in konkrete Aufgaben auf. Eine mit 30 Stunden angesetzte Implementierungsphase braucht Angaben dazu, welche Arbeiten in dieser Zeit stattfinden.

Für das betrachtete 70-Stunden-Projekt empfehle ich als Daumenregel eine bis sieben Stunden je Aufgabe. Sieben Stunden entsprechen einem Zehntel der gesamten Projektzeit. Das ist eine Empfehlung für eine nachvollziehbare Gliederung.

Beschreibe beispielsweise, welche Oberflächen du entwirfst. Der Plan soll zeigen, dass du die Arbeit durchdacht hast, und zugleich übersichtlich bleiben.

Plane auch bei agilen Prozessen deine Iterationen innerhalb der verfügbaren Zeit. So lässt sich einschätzen, welchen Umfang du bis zum Projektende schaffen kannst.

Den Entwicklungsprozess begründen

Benenne ausdrücklich, nach welchem Prozess du arbeitest. Dadurch kann ein:e Prüfer:in nachvollziehen, wie deine Projektphasen zustande kommen und ob deine Zeitansätze realistisch sind.

Begründe, warum der Prozess zu deinem Projekt passt. Dabei kannst du seine Vor- und Nachteile erläutern. Ob du Wasserfall, V-Modell oder einen agilen Prozess wählst, hängt von deinem Projekt ab.

Für ein bekanntes Modell wie Wasserfall reicht eine kurze Beschreibung. Einen selbst zusammengestellten Prozess, etwa mit Test-Driven Development, solltest du ausführlicher darstellen. Dafür kommen einige Sätze bis etwa eine halbe Seite infrage.

Begründe auch deine weiteren Entscheidungen, denn das gehört zu den Punkten, die bei der Projektdokumentation bewertet werden.

Ressourcen vollständig erfassen

Liste auf, welche Hardware und Software du brauchst. Dazu können dein Arbeitsplatz, ein Gerät zum Testen und kostenpflichtige Lizenzen gehören. Eine Übersicht im Anhang bietet dafür Platz.

Plane die Arbeitszeit weiterer Beteiligter ein, etwa für Besprechungen, Code-Reviews oder Abnahmetests.

Berücksichtige vorhandene Infrastruktur und bereits beschäftigte Kolleg:innen bei den Kosten. Auch ein Server, der schon im Unternehmen steht, verursacht Kosten, die anteilig auf Projekte entfallen. Solche als "Eh-da-Kosten" bezeichneten Aufwände gehören in deine Rechnung.

Analysephase

Prüfen, ob sich das Projekt lohnt

Ermittle, warum das Projekt umgesetzt werden soll und welchen wirtschaftlichen Ertrag es für das Unternehmen bringt. Die Wirtschaftlichkeitsbetrachtung gehört in die Analysephase; fehlt sie, kann das zu Punktabzug führen.

Erfasse deine eigene Arbeitszeit und die anteiligen Kosten der benötigten Ressourcen. Rechne ebenso die Arbeitszeit von Kolleg:innen ein, die dein Projekt unterstützen.

Bei einem beispielhaften Stundensatz von 50 Euro kosten vier Stunden Unterstützung durch dein:e Ausbilder:in bereits 200 Euro.

Berechne, welche Ausgaben das Projekt künftig einspart. Wenn eine eigene Software eine bisher eingekaufte Lösung ersetzt, können beispielsweise Lizenz- oder Wartungsgebühren entfallen. Auch die laufenden Kosten der eigenen Lösung gehören in die Rechnung.

Mit einer Amortisationsrechnung bestimmst du, ab wann die Einsparungen die Projektkosten decken. Bei langfristig geplanter Software kann dieser Zeitpunkt mehrere Jahre entfernt liegen.

Prüfe anhand der Zahlen, ob das Projekt wirtschaftlich sinnvoll ist. Ein Projekt, das Geld kostet und keinen wirtschaftlichen Ertrag bringt, sollte bereits bei der Themenwahl ausscheiden.

Make-or-Buy-Entscheidung dokumentieren

Recherchiere, welche fertigen Softwareprodukte am Markt verfügbar sind. Prüfe deren Kosten und wie sie die Anforderungen deines Unternehmens abdecken.

Reserviere für diese Recherche Zeit im Projektplan. Als Beispiel nenne ich ein bis zwei Stunden.

Begründe anhand deiner Ergebnisse, warum du selbst entwickelst. Wenn vorhandene Produkte benötigte Funktionen nicht abdecken, halte konkret fest, welche Anforderungen offenbleiben. Die Aussage, dein Unternehmen habe individuelle Anforderungen, braucht Belege.

Besonders bei häufig gelösten Aufgaben wie Zeiterfassung oder Projektverwaltung gehört diese Prüfung zur fachlichen Begründung des Projekts. Die Make-or-Buy-Entscheidung kann auch im Fachgespräch aufgegriffen werden.

Anwendungsfälle mit einem Use-Case-Diagramm beschreiben

Stelle dar, welche Akteur:innen mit deinem System arbeiten und welche Anwendungsfälle sie ausführen können. Im UML-Use-Case-Diagramm stehen die Anwendungsfälle als Ovale innerhalb der Systemgrenze; Verbindungen ordnen sie den Akteur:innen zu.

Besprich das Diagramm mit deinem/deiner Kund:in, um den vorgesehenen Funktionsumfang abzustimmen und fehlende Anwendungsfälle zu erkennen.

Ich empfehle ein Use-Case-Diagramm für jede Projektdokumentation als Einstieg in die fachlichen Anforderungen. Es ist außerdem für die schriftliche Abschlussprüfung relevant.

Anforderungen schriftlich festhalten

Dokumentiere, was dein System fachlich leisten soll. In der Projektdokumentation sollten mindestens Auszüge dieser Anforderungen enthalten sein. Daraus muss später erkennbar werden, ob die geforderten Funktionen erfüllt wurden.

Ein Lastenheft hält die fachlichen Anforderungen des/der Kund:in fest. Im späteren Pflichtenheft beschreibst du die technische Umsetzung.

Du kannst Anforderungen auch durch andere geeignete Formen festhalten. Ein Aktivitätsdiagramm kann beispielsweise einen einzelnen Anwendungsfall genauer beschreiben.

User Stories folgen dem Muster "Als X möchte ich Y, damit Z". Sie benennen die Rolle und die gewünschte Aktion samt Zweck. Ich verwende sie auch außerhalb agiler Projekte, weil sich Anforderungen damit einheitlich und verständlich formulieren lassen.

Mit MoSCoW priorisierst du Anforderungen: Must kennzeichnet zwingend erforderliche Funktionen,...

In der siebenundzwanzigsten Episode des Anwendungsentwickler-Podcasts gehe ich die Punkte einer sinnvollen Gliederung der Projektdokumentation (bis zur Einleitung) durch.

TL;DR

Beim Lesen deiner Projektdokumentation achte ich darauf, dass ich deinen Projektablauf und deine eigene Arbeit nachvollziehen kann. Dafür richtest du die Gliederung an deinem Vorgehen aus und hältst die Vorgaben deiner IHK ein. Nach den Deckblättern und passenden Verzeichnissen folgt eine verständliche Einleitung, aus der auch eine branchenfremde Person dein Projektziel und die Schnittstellen erkennt. Meine kostenlose Vorlage hilft dir beim Aufbau, wobei du sämtliche Inhalte mit deiner eigenen Projektarbeit füllst.

Kapitelmarken

[00:00:00] Thema und weiterführende Website

[00:00:30] Die Projektdokumentation in der Abschlussprüfung

[00:02:22] Kostenlose LaTeX-Vorlage und Beispiel-PDF

[00:03:49] Eigene Inhalte und verantwortlicher Umgang mit der Vorlage

[00:06:28] Die Gliederung am Projektablauf ausrichten

[00:07:52] IHK-Formblatt und Vorgaben zur Abgabe

[00:09:14] Das eigene Deckblatt gestalten

[00:11:55] Inhaltsverzeichnis und praxisbezogener Projektbericht

[00:14:01] Weitere Verzeichnisse und formale Qualität

[00:15:36] Seitenumfang, Leerflächen und große Abbildungen

[00:17:21] Abkürzungsverzeichnis und Glossar

[00:19:29] Eine verständliche Einleitung schreiben

[00:22:24] Projektbeschreibung und Anlass des Projekts

[00:23:46] Personelle und technische Schnittstellen

[00:24:35] Projektabgrenzung und eigene Arbeit

[00:26:51] Ausblick auf weitere Inhalte der Projektdokumentation

[00:27:46] Früh beginnen und die Vorlage herunterladen

[00:28:26] Lizenz und Quellenhinweis zur Vorlage

[00:29:03] Feedback zur Vorlage und LaTeX-Einstiegskurs

[00:30:21] Rückmeldungen zum Podcast

[00:31:00] Newsletter und Checklisten für die Abschlussprüfung

Inhalt

Formblatt der IHK

Deckblatt

Name des Prüflings

Projektname und -thema

Datum

Logos der IHK und des Unternehmens sind nett

Verzeichnisse

Inhalt

Abbildungen

Tabellen

Listings

Abkürzungen

keine allgemein bekannten Abkürzungen aufnehmen

Einleitung

Projektbeschreibung (Ziel, Begründung)

Schnittstellen

Projektabgrenzung

Literaturempfehlungen

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Themenfindung für das Abschlussprojekt - Anwendungsentwickler-Podcast #24

Inhalte des Projektantrags - Anwendungsentwickler-Podcast #25

Vorlage für die Projektdokumentation

Einführung in LaTeX: 00. Einleitung

Weitere Infos zur ProjektdokumentationDu suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.Jetzt anmelden!

Zusammenfassung

Gliederung passend zu deinem Projekt

Als Prüfer lese ich deine Projektdokumentation, um nachzuvollziehen, wie du dein Projekt umgesetzt hast. Alles, was du darin beschreibst, muss zu deiner geleisteten Arbeit passen. Die Dokumentation gehört zusammen mit der Präsentation zu den Teilen der Abschlussprüfung, die du selbst gestalten kannst. Plane dafür ausreichend Zeit ein und beginne früh mit dem Schreiben.

Orientiere die Gliederung an deinem tatsächlichen Projektablauf. Wenn du agil entwickelt hast, muss dieses Vorgehen auch im Aufbau erkennbar sein.

Passe die Kapitel einer Vorlage an dein Projekt an. Welche Inhalte an welcher Stelle stehen, hängt von deiner Arbeit ab.

Der hier beschriebene Aufbau reicht bis zur Einleitung. Die weiteren Projektphasen folgen in einer späteren Episode.

Meine Vorlage als Hilfe beim Schreiben

Auf meiner Website findest du eine kostenlose Vorlage für LaTeX sowie ein daraus erzeugtes PDF. Darin stehen Beispielinhalte und Hinweise auf weiterführende Literatur. An den enthaltenen Abbildungen kannst du sehen, wie sich solche Inhalte in die Dokumentation einfügen lassen.

Du kannst das Layout und den Aufbau übernehmen, während du die fachlichen Inhalte selbst verfasst.

Passe auch Beispielrechnungen an deine echten Projektdaten an. Dazu gehören etwa die Stundensätze.

Prüfer:innen kennen solche Vorlagen. Unverändert übernommene Inhalte können zu einer schlechten Bewertung führen und Fragen nach einem Plagiat aufwerfen.

Die Vorlage hilft dir dabei, an relevante Projektbestandteile zu denken und Ideen für deine eigene Arbeit aufzugreifen.

Formblatt und eigenes Deckblatt

Bei meiner IHK beginnt die abgegebene PDF-Datei mit einem vorgeschriebenen Formblatt. Darauf stehen Angaben zu dir und deinem Ausbildungsbetrieb sowie das Projektthema und der Abgabetermin. Die Datei wird online im Prüfungssystem hochgeladen. Welche Regeln für dich gelten, ergibt sich aus den Vorgaben deiner IHK.

Achte auf verpflichtende Inhalte und deren vorgeschriebene Position. Auch Vorgaben zu Leerseiten gehören dazu, sofern deine IHK sie verlangt.

Fehlende Pflichtbestandteile können als Formfehler zu Punktabzug führen.

Auf das Formblatt folgt häufig ein selbst gestaltetes Deckblatt. Ein Firmenlogo kann es optisch ergänzen.

Platziere das Projektthema gut sichtbar. Ein prägnanter Titel hilft mir, deine Arbeit beim Lesen mehrerer Dokumentationen wiederzuerkennen.

Auf das Deckblatt gehören außerdem dein Name und Angaben zum Ausbildungsbetrieb. Ergänze das Datum, die zuständige IHK sowie deine Anschrift und Kontaktdaten. In manchen IHKs werden Prüflinge beispielsweise kontaktiert, um Quelltext nachzureichen.

Inhaltsverzeichnis und weitere Verzeichnisse

Ich schaue mir das Inhaltsverzeichnis an, um einen Überblick über die Kapitel zu bekommen. Dabei erkenne ich, ob die Projektphasen sinnvoll angeordnet sind und beispielsweise die Kostenplanung an einer passenden Stelle steht. Das Inhaltsverzeichnis gehört direkt hinter das Deckblatt.

Ergänze Verzeichnisse für Abbildungen und Tabellen, sofern diese Inhalte vorkommen. Für Quelltextausschnitte ist ein Listingsverzeichnis sinnvoll.

Erzeuge Verzeichnisse mit deiner Textverarbeitung automatisch und prüfe anschließend die Verweise. Nummern und Referenzen müssen stimmen.

Kurze Verzeichnisse können gemeinsam auf einer Seite stehen.

Deine Dokumentation ist ein praxisbezogener Projektbericht. Dazu passen ein Quellenverzeichnis und sauber nummerierte Seiten. Eine Danksagung oder ein Abstract halte ich für diesen Rahmen für überzogen.

Als angehende:r Fachinformatiker:in Anwendungsentwicklung solltest du mit der eingesetzten Textverarbeitung umgehen können. Fehler bei Verweisen können ebenso wie Rechtschreibfehler oder ein unpassendes Layout in die Bewertung einfließen.

Seitenvorgaben und Platz im Fließtext

Bei meiner IHK sind 15 Seiten Fließtext vorgegeben. Ich prüfe beim Lesen, wie viel davon mit Text gefüllt ist, und ziehe größere Leerflächen sowie umfangreiche Grafiken oder Tabellen davon ab. Diese Vorgehensweise beschreibt meine Prüfpraxis im genannten IHK-Rahmen.

Richte dich nach den Seitenvorgaben deiner IHK.

Verschiebe große Abbildungen und umfangreiche Tabellen in den Anhang.

Achte darauf, dass Seitenumbrüche keine großen leeren Flächen erzeugen.

Die aufgedruckte letzte Seitenzahl allein zeigt den Umfang des Fließtextes nur unzureichend. In meiner Bewertung können Abweichungen von der Vorgabe zu Punktabzug führen.

Abkürzungen verständlich machen

Im Abkürzungsverzeichnis löst du projektbezogene Kürzel auf. Besonders bei internen Begriffen aus deinem Betrieb oder deiner Branche brauchen Leser:innen diese Hilfe.

DSL kann beispielsweise "Domain Specific Language" bedeuten, während die Abkürzung vielen als "Digital Subscriber Line" bekannt ist. Halte die Bedeutung in deinem Projekt fest.

Auch ein technisches Kürzel wie GUI für "Graphical User Interface" darf aufgenommen werden.

Allgemein bekannte Schreibweisen wie "z. B." brauchen keinen eigenen Eintrag.

Ein Glossar würde ich hinter dem Fließtext platzieren. Das Abkürzungsverzeichnis schließt die Verzeichnisse vor dem eigentlichen Text ab.

Die Einleitung: Dein Projekt verständlich beschreiben

Nach der ersten halben Seite möchte ich bereits verstehen, welche Aufgabe du bearbeitest. Schreibe deshalb so, dass eine Person außerhalb deines Unternehmens und deiner Branche dem Projekt folgen kann. Branchenspezifische Fachbegriffe erklärst du dort, wo sie zum Verständnis gebraucht werden.

Projektbeschreibung und Anlass

Beschreibe das Ziel und den Inhalt deines Projekts.

Begründe, weshalb das Projekt umgesetzt wird. Die ausführliche Wirtschaftlichkeitsanalyse kann später folgen.

Wenn du eigene Software entwickelst, muss der Anlass dafür nachvollziehbar sein. Die pauschale Behauptung, am Markt gebe es keine passende Software, ist als Begründung wenig überzeugend.

Schnittstellen und eigene Arbeit

Benenne die personellen Schnittstellen, also etwa Kolleg:innen, mit denen du zusammenarbeitest.

Beschreibe die technischen Schnittstellen und die Anforderungen, die sich daraus für deine Arbeit ergeben.

Bei einem Teilprojekt muss erkennbar sein, welchen Anteil du selbst bearbeitest. Kennzeichne vorhandene Bestandteile und Arbeiten anderer Beteiligter ausdrücklich.

Das gilt auch für Diagramme und Datenbankmodelle. Gerade bei Änderungen an bestehenden ERP-Systemen können dargestellte Strukturen bereits vorhanden sein.

Bei einem vollständig eigenständigen Projekt kann eine gesonderte Projektabgrenzung entfallen.

Weiterführende Materialien

Die Shownotes mit dem Link zur Vorlage findest du unter anwendungsentwicklerpodcast.de/27. Weitere Informationen zur Projektdokumentation stehen auf dieperfekteprojektdokumentation.de.

Meine Vorlage steht unter einer Creative-Commons-Lizenz. Vermerke meinen Namen und meine Website im Quelltext; ein sichtbarer Hinweis im abgegebenen PDF ist dafür entbehrlich.

Auf meiner Website findest du einen LaTeX-Einstiegskurs mit zehn Videos....

In der sechsundzwanzigsten Episode des Anwendungsentwickler-Podcasts gebe ich Tipps für andere interessante Podcasts für Softwareentwickler.

TL;DR

Ich empfehle dir Podcasts, mit denen du als IT-Azubi dein Wissen über Softwareentwicklung erweitern und Einblicke in den Berufsalltag von Softwareentwickler:innen bekommen kannst. Die Auswahl reicht von allgemeinen Architekturthemen bis zu einzelnen Plattformen und schließt auch Karrierefragen sowie Themen abseits des Programmierens ein. Für den Einstieg eignet sich besonders CodeNewbie; Rechtsbelehrung behandelt außerdem Rechtsthemen, die in deiner IHK-Abschlussprüfung vorkommen können.

Kapitelmarken

[00:00:01] Thema und Überblick über die Podcast-Empfehlungen

[00:01:46] Software Engineering Radio

[00:03:05] SoftwareArchitekTOUR und Heise Developer

[00:04:26] CodeNewbie: Programmieren lernen

[00:05:51] INNOQ Podcast: Technik aus der Praxis

[00:06:59] This Developer’s Life: Alltag als Softwareentwickler:in

[00:08:14] Hanselminutes

[00:09:14] .NET Rocks!

[00:11:18] Herding Code

[00:12:10] This Week on Channel 9

[00:12:55] Java Posse und das Folgenarchiv

[00:14:04] Java Pub House

[00:14:49] Illegal Argument

[00:15:35] Ruby Rogues

[00:16:54] Functional Geekery: Funktional programmieren

[00:18:24] Test Talks: Software automatisiert testen

[00:19:29] JavaScript Jabber

[00:20:47] RunAs Radio: Administration im Microsoft-Umfeld

[00:22:12] c’t uplink: Aktuelle IT-Themen

[00:23:40] Career Tools und Manager Tools

[00:25:11] Beyond the To-Do List: Arbeit organisieren

[00:26:32] Get Up & Code: Fitness im Entwickler:innenalltag

[00:27:59] Rechtsbelehrung: Recht für Praxis und Prüfung

[00:29:31] CRE: Technik, Kultur und Gesellschaft

[00:30:38] PC Games Podcast

[00:32:06] Weitere Empfehlungen und Shownotes

[00:33:14] Feedback, Rezensionen und Kontakt

[00:34:05] Newsletter und Checklisten für dein Abschlussprojekt

Inhalt

Softwareentwicklung allgemein

Software Engineering Radio

heise Developer

CodeNewbie

innoQ Podcast

This Developer's Life

Hanselminutes

Softwareentwicklung speziell

.NET

.NET Rocks!

Herding Code

This Week On Channel 9

Java

The Java Posse (eingestellt)

Java Public House

Illegal Argument

Ruby Rogues

Functional Geekery

Test Talks

JavaScript Jabber

Administration

RunAs Radio

c't uplink

Karriere

Career Tools

Beyond the To Do List

Sonstiges

Get up and CODE!

Rechtsbelehrung

CRE: Technik, Kultur, Gesellschaft

PC Games Podcast

Du willst selbst einen Podcast aufnehmen? Ich verwende dazu dieses Mikrofon, das ich uneingeschränkt weiterempfehlen kann:

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

The Ultimate List Of Developer Podcasts - Simple Programmer

Samson Meteor Mic USB Studio/Podcast Mikrofon silber*

Zusammenfassung

Allgemeine Softwareentwicklung

Ich höre Podcasts zu technischen Fragen und zum Alltag als Softwareentwickler:in. Aus meiner Liste empfehle ich dir folgende Formate:

Software Engineering Radio: Der englischsprachige Podcast entsteht im Umfeld des IEEE Software Magazins. Internationale Expert:innen sprechen über aktuelle Entwicklungen und vertiefen Architekturfragen. Die Folgen dauern meist etwa eine Stunde, wobei die Tonqualität gelegentlich schwankt.

SoftwareArchitekTOUR / Heise Developer Podcast: Deutschsprachige Softwareentwickler:innen diskutieren ausführlich über Architektur und übergreifende Fragen der Softwareentwicklung. Die unregelmäßig erscheinenden Folgen dauern häufig länger als eine Stunde und greifen auch neue Themen auf.

CodeNewbie: Dieser englischsprachige Podcast richtet sich an Einsteiger:innen. Besonders die frühen Folgen behandeln, wie du programmieren lernst, passende Projekte findest und Feedback bekommst. Im Verlauf werden die Themen anspruchsvoller, bleiben aber für Anfänger:innen zugänglich.

INNOQ Podcast: Mitarbeiter:innen von INNOQ sprechen auf Deutsch über konkrete Technologien wie REST oder Ruby. Auch Architektur und Usability kommen vor. Die häufig über einstündigen Gespräche vermitteln Erfahrungen aus der täglichen Arbeit, etwa zur Frage, welche Frameworks sich für Webprojekte eignen.

This Developer’s Life: Scott Hanselman und Rob Connery behandeln das Leben von Softwareentwickler:innen. Dabei geht es etwa darum, wie du mit Kritik oder Druck umgehst. Persönliche Erfahrungen der Gäste bekommen viel Raum, bis hin zu schweren Erkrankungen in der Familie.

Hanselminutes: Scott Hanselman führt etwa halbstündige Gespräche mit Gästen aus der Softwareentwicklung. Sein beruflicher Hintergrund bei Microsoft prägt die Themenauswahl. Der eigenständig betriebene Podcast behandelt außerdem Open Source und Webentwicklung sowie Usability.

Einzelne Plattformen und technische Schwerpunkte

.NET und Microsoft

.NET Rocks!: Carl Franklin und Richard Campbell führen seit 2002 Interviews. Zum Zeitpunkt meiner Empfehlung sind bereits mehr als 1.000 Folgen erschienen. Neben .NET kommen allgemeine Technologien vor; die "Geek-Out"-Folgen beschäftigen sich beispielsweise mit Energiefragen oder Kaffee. Die etwa einstündigen Episoden bieten ausführliche Gespräche und eine hohe Tonqualität.

Herding Code: Erfahrene Entwickler:innen sprechen detailliert über .NET, mit einem Schwerpunkt auf Webentwicklung rund um ASP.NET und MVC. Die Folgen dauern ungefähr eine Stunde und eignen sich besonders, wenn du mit diesen Technologien arbeitest.

This Week on Channel 9: Das Format aus dem Hause Microsoft fasst wöchentlich Neuigkeiten aus dem Microsoft- und .NET-Umfeld zusammen. Links zu Artikeln helfen dir, einzelne Themen weiterzuverfolgen.

Java

Java Posse: Anfang 2015 wurde der Podcast eingestellt. Die fast 500 archivierten Folgen enthalten ausführliche Gespräche über Java-Technologien. Beim Anhören solltest du berücksichtigen, wie alt die jeweilige Folge ist. Ich suche weiterhin nach einem vergleichbaren Java-Podcast.

Java Pub House: Etwa einstündige Episoden führen auch auf Einsteigerniveau in Technologien wie Hibernate oder Spring MVC ein. Das Format eignet sich ebenfalls für fortgeschrittene Java-Entwickler:innen.

Illegal Argument: Entwickler:innen aus Neuseeland diskutieren ausführlich über Java. Ihre teils kontroversen Ansichten regen dazu an, dir eine eigene Meinung zu bilden. Wenn du amerikanisches Englisch gewohnt bist, braucht der Akzent etwas Eingewöhnung.

Weitere technische Themen

Ruby Rogues: Ein wechselndes Panel aus Ruby-Expert:innen spricht wöchentlich über Ruby und Ruby on Rails. Auch allgemeine Webthemen und Open Source finden Platz. Das von Charles Max Wood gegründete Format verbindet technische Inhalte mit lockeren Gesprächen.

Functional Geekery: Der Podcast beschäftigt sich mit funktionalem Programmieren und entsprechenden Sprachen. Gäste berichten aus ihrer täglichen Arbeit. Wenn du bisher vor allem objektorientiert programmierst, bekommst du Einblicke in andere Ansätze. Funktionale Konzepte finden zunehmend auch Eingang in Java und C#.

Test Talks: Hier geht es um Softwaretests über Sprachgrenzen hinweg, besonders um automatisierte Tests. Du lernst Frameworks und Möglichkeiten kennen, mit denen sich unterschiedliche Teile einer Anwendung testen lassen. Ich setze mich für automatisierte Tests und Test-Driven Development ein.

JavaScript Jabber: Ebenfalls von Charles Max Wood stammt dieses Panel-Format rund um JavaScript und Frontends. Die Gespräche helfen dir, Frameworks einzuordnen und zu erfahren, welche Technologien andere Entwickler:innen einsetzen.

Administration und allgemeine IT

RunAs Radio: Richard Campbell interviewt wöchentlich Expert:innen aus dem IT-Betrieb. Die etwa halbstündigen Folgen haben einen deutlichen Microsoft-Schwerpunkt, etwa bei Windows-Verwaltung und PowerShell. Als Anwendungsentwickler:in bekommst du Einblicke in die Systeme, auf denen deine Software läuft.

c’t uplink: Die c’t-Redaktion bespricht wöchentlich aktuelle Themen aus dem Heft. Du erhältst einen Überblick über IT-Neuigkeiten und Geräte. Das Format gibt es als Audio und Video, sodass du vorgestellte Hardware auch sehen kannst.

Karriere und produktiver arbeiten

Career Tools / Manager Tools: Beide Podcasts stammen vom Team um Mark Horstman. Für dich als Mitarbeiter:in empfehle ich besonders Career Tools, etwa zu Bewerbungen und Vorstellungsgesprächen oder dazu, wie du beruflich vorankommst. Die Empfehlungen orientieren sich am US-amerikanischen Arbeitsmarkt; viele Inhalte lassen sich auf den deutschsprachigen Raum übertragen.

Beyond the To-Do List: Erik Fisher spricht über Werkzeuge und Methoden, mit denen du deinen Arbeitstag organisierst, darunter Getting Things Done und die Pomodoro-Technik. Auch die Balance zwischen Arbeit und Privatleben wird behandelt. Die Folgen dauern ungefähr 45 bis 60 Minuten.

Gesundheit, Recht und Freizeit

Get Up & Code: Der Podcast verbindet Fitness mit dem Alltag von Softwareentwickler:innen. Du bekommst Anregungen zu Ernährung und Sport sowie Erfahrungsberichte von Menschen, die neben ihrer Arbeit am Schreibtisch körperlich aktiv bleiben.

Rechtsbelehrung: Der deutschsprachige Podcast behandelt vor allem Rechtsfragen im Onlinebereich. Ein als Rechtsanwalt tätiger Host bringt Beispiele aus seiner Praxis ein. Für dich als IT-Azubi sind etwa Urheberrecht und Datenschutz relevant; auch das Recht am eigenen Bild und Persönlichkeitsrechte können in der IHK-Abschlussprüfung vorkommen. Manche Folgen dauern anderthalb bis zwei Stunden.

CRE, ursprünglich Chaosradio Express: Die ausführlichen Gespräche mit Gästen behandeln Technik sowie Kultur und Gesellschaft. Zu meinen Lieblingsfolgen gehören Gespräche über LaTeX und Wikipedia. Die Folgen erscheinen unregelmäßig und können mehrere Stunden dauern.

PC Games Podcast: Die Redaktion bespricht aktuelle Spiele und beantwortet Fragen von Hörer:innen. Einzelne Spiele werden ausführlich analysiert, während eine ganze Folge häufig mehr als zwei Stunden dauert. Das Format wird auch als Video angeboten.

Empfehlungen austauschen und weitere Inhalte bekommen

Unter anwendungsentwicklerpodcast.de/26 findest du die Shownotes....

In der fünfundzwanzigsten Episode des Anwendungsentwickler-Podcasts erläutere ich die Inhalte des Projektantrags für das Abschlussprojekt und worauf man bei der Formulierung achten sollte.

TL;DR

Mit deinem Projektantrag müssen Prüfer:innen beurteilen können, ob dein IHK-Abschlussprojekt fachlich und wirtschaftlich zu deinem Beruf passt. Beschreibe dafür das betriebliche Problem und dein Ziel so genau, dass dein eigener Anteil und der technische Umfang erkennbar werden. Plane einen passenden Entwicklungsprozess mit nachvollziehbaren Arbeitsschritten; berücksichtige dabei auch Wirtschaftlichkeit, Qualitätssicherung und die erforderlichen Dokumentationen. Ich empfehle dir, früh das Formular deiner IHK zu besorgen und den Antrag lokal vorzubereiten, damit genug Zeit zum Prüfen und fristgerechten Einreichen bleibt.

Kapitelmarken

[00:00:01] Einstieg: Inhalte des Projektantrags

[00:00:35] Warum die Qualität des Antrags zählt

[00:01:53] Projektname und Kurzbezeichnung

[00:03:56] Das Projekt für betriebsfremde Prüfer:innen beschreiben

[00:05:39] Ist-Analyse und betrieblicher Bedarf

[00:06:59] Soll-Konzept und technischer Umfang

[00:08:39] Bekannte Details und geplante Technologieauswahl

[00:10:48] Wirtschaftlichkeit und Amortisation

[00:12:09] Geplante Diagramme und Entwicklungsartefakte

[00:14:19] Einen passenden Entwicklungsprozess wählen

[00:16:08] Projektablauf und Zeitverhältnisse

[00:19:01] Plattform der Anwendung angeben

[00:19:54] Komponenten und eigene Leistungen sichtbar machen

[00:21:12] Frühes Feedback zum Projektumfang

[00:22:48] Lange Projektphasen in Arbeitsschritte aufteilen

[00:24:22] Qualitätssicherung einplanen

[00:25:10] Dokumentation für Kund:innen und Entwickler:innen

[00:25:44] IHK-Vorgaben zur Zeit für die Projektdokumentation

[00:26:39] Eigenen Anteil vom Gesamtprojekt abgrenzen

[00:28:02] Fachliche und wirtschaftliche Tiefe erkennbar machen

[00:28:44] IHK-Formular früh besorgen und Zeit einplanen

[00:30:22] Antrag lokal schreiben und Korrektur lesen

[00:31:46] Präsentationsmittel rechtzeitig angeben

[00:33:03] Formblätter und Kontaktdaten prüfen

[00:33:57] Fristen und Freigabe durch Ausbilder:innen beachten

[00:35:41] Shownotes und Feedback

[00:36:51] Newsletter und Checklisten für das Abschlussprojekt

Inhalt

Sprechenden Namen und Kurzbezeichnung für das Projekt verwenden.

Für betriebsfremde Personen (nicht technische Laien!) das Projektthema verständlich erklären.

Kurze Ist-Analyse mit Beschreibung der Schwachstellen durchführen.

Soll-Konzept beschreiben.

Wirtschaftlichkeitsbetrachtung einplanen.

Zu verwendende Methoden und zu erzeugende Artefakte benennen.

Entwicklungsprozess definieren.

Sinnvollen Projektablauf planen.

Auf sinnvolles Verhältnis der einzelnen Projektphasen achten.

Geplante Form des Programms und ggfs. Plattform nennen (z.B. Webanwendung mit Java).

Alle notwendigen Komponenten aufführen (Datenbank, GUI, Logik, Web).

Implementierungsphase auf einzelne Komponenten herunterbrechen (max. 8h).

Qualitätssicherung einplanen.

Dokumentationen einplanen.

Bei Teilprojekten Thema klar von restlichen Projekten abgrenzen (Eigenleistung).

Konkrete Tipps

Die Prüfer müssen erkennen können, ob das Projekt zum Berufsbild passt und die notwendige technische Tiefe bzw. einen angemessenen Umfang hat.

Konkreten Projektantrag der eigenen IHK besorgen und auf Besonderheiten achten.

Auch bei Online-Systemen den Antrag zunächst offline schreiben.

Ggfs. alle möglichen Präsentationsmittel auswählen.

Formblätter exakt ausfüllen.

Fristen penibel einhalten, ggfs. muss der Ausbilder noch online bestätigen.

Beispielantrag

Hier kannst du dir einen sehr guten Beispielantrag anschauen, der die obigen Punkte umsetzt:

Meine Checkliste zur Prüfung von Projektanträgen

Beim Prüfen von Projektanträgen für die IHK-Prüfung achte ich immer insb. auf die folgenden Punkte. Du kannst die Liste gerne nutzen um deinen eigenen Antrag auf Vollständigkeit und aussagekräftigen Inhalt zu überprüfen.

Projektbegründung

Wird das Projekt nachvollziehbar eingeführt und beschrieben?

Viele Prüflinge schreiben so, als wüsste jeder Prüfer, wie die internen Abläufe und Probleme im Unternehmen des Prüflings oder auch branchenspezifische Fragestellungen aussehen. Das ist nicht der Fall! Ein paar Sätze zum Unternehmen und der Problemstellung sollten selbstverständlich sein.

Was ist der wirtschaftliche Nutzen? Wird eine Kalkulation/Amortisationsrechnung durchgeführt?

Viele Prüflinge konzentieren sich ausschließlich auf den technischen Teil des Projekts (insb. die Programmierung) und vergessen den wirtschaftlichen Teil völlig. Solche Anträge gehen immer mit Änderungsauftrag zurück an den Prüfling.

Projektplanung

Ist der Aufbau der zeitlichen Projektplanung logisch und sinnvoll?

Einige Prüflinge setzen für die einzelnen Phasen des Projekts unrealistische Zeiten ein oder brechen sie nicht detailliert genug runter. So wird häufig die Implementierung z.B. einfach mit 35 Stunden angesetzt ohne genauer zu beschreiben, welche Komponenten entwickelt werden sollen und wie viel Zeit jeweils auf diese entfällt. Unbedingt erforderlich ist natürlich auch die Einhaltung der zeitlichen Vorgabe von 70 Stunden!

Stimmt das Verhältnis zwischen Entwurf und Implementierung?

Das Projekt sollte methodisch umgesetzt werden und nicht einfach "drauflos programmiert". Daher ist eine entsprechend lange Entwurfsphase mit sinnvollen Entwurfsmethoden (z.B. Komponentendiagramm, Entity-Relationship-Model) im Verhältnis zur Implementierung anzuraten.

Wurde die Dokumentation in der Zeitplanung berücksichtigt?

Für das Projekt sollten (in den meisten Fällen) verschiedene Dokumentationen angefertigt werden, die sich nicht von alleine schreiben. Es sollte also ausreichend Zeit dafür eingeplant sein.

Implementierung

Welche Form hat das Programm (Webanwendung, Client mit GUI, CLI)?

Es ist erstaunlich aus wie vielen Projektanträgen nicht hervorgeht, welche Form das zu erstellende Programm eigentlich hat. Das ist aber durchaus interessant für die Prüfer, um die Projektplanung bewerten zu können (z.B. ob die Zeiten realistisch oder die Tests ausreichend sind).

Welche Programmiersprache/Datenbank wird verwendet?

Falls die technischen Details der Implementierung nicht erst während der Projektphase bestimmt werden (was wohl in den seltensten Fällen so ist), dürfen diese Informationen gerne deutlich im Projektantrag genannt werden.

Wie wird getestet bzw. welche Maßnahmen zur Qualitätssicherung werden angewendet?

Trotz dreijähriger Ausbildung sind die Prüflinge (und sicherlich auch die Ausbilder) nicht perfekt. Wie wird im Projekt also dafür gesorgt, dass ein vernünftiges Produkt erstellt wird? Hier dürfen ausgedehnte Testphasen, Test Driven Development oder auch Code Reviews eingeplant werden.

Sonstiges

Welche Methoden werden eingesetzt und welche Artefakte werden erstellt?

UML-Diagramme, ERM, Tabellenmodelle, Ablaufpläne, EPKs, Programmablaufpläne, Nutzwertanalysen, Mockups usw.

Und ganz wichtig: Was ist die konkrete Eigenleistung des Prüflings?

Häufig wird das Projekt so schwammig beschrieben, dass nicht ersichtlich ist, was genau der Prüfling eigentlich macht. In einigen Projekten muss man sich fragen, ob überhaupt eine Zeile Code produziert wird. Gerade bei Integrationsprojekten in großen Unternehmensanwendungen ist der organisatorische Overhead so groß, dass nur noch wenig Zeit für die Implementierung bleibt. Das wird aber in einem Abschlussprojekt erwartet.

Literaturempfehlungen

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Ist die Projektdokumentation Teil der Bearbeitungszeit des IHK-Abschlussprojekts?

Durchführungszeitraum des Abschlussprojekts

Beispiel für einen Projektantrag (ab Seite 7), IHK Hannover

Inhalt und Genehmigungskriterien für den Projektantrag, IHK Nord Westfalen

Weitere Infos zum ProjektantragDu suchst noch mehr Tipps rund um den Projektantrag? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um den Projektantrag.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für den Projektantrag herunterladen.Jetzt anmelden!

Zusammenfassung

Wozu dein Projektantrag dient

Anhand deines Antrags entscheiden Prüfer:innen, ob dein Abschlussprojekt zum Beruf Fachinformatiker:in Anwendungsentwicklung passt und ausreichend fachliche sowie wirtschaftliche Tiefe hat. Je genauer du dein Vorhaben beschreibst, desto besser können sie den Umfang beurteilen. Wenn Angaben fehlen, können Rückfragen oder eine Ablehnung dazu führen, dass du den Antrag überarbeiten musst und später mit dem Projekt beginnst.

Aus meiner Erfahrung als Prüfer gehört deshalb bereits beim Antrag ein hoher Qualitätsmaßstab dazu. Eine Genehmigung allein sichert dir keine gute Note: Bewertet wird später, was du im Projekt geleistet hast. Frühes Feedback zu einem zu einfachen Thema gibt dir Zeit, den Umfang anzupassen oder ein anderes Thema zu wählen.

Projektname und verständliche Beschreibung

Wähle einen Titel, aus dem dein Vorhaben hervorgeht, etwa "Entwicklung einer webbasierten Anwendung zur Verwaltung einer Fachbuchsammlung". Eine kurze Bezeichnung erleichtert dir außerdem, in der Dokumentation und während der Präsentation auf dein Projekt zu verweisen. Bei einem Abschlussprojekt aus meinem Ausbildungsalltag hieß diese Kurzbezeichnung "Routing DSL".

Prüfer:innen bringen IT-Fachwissen mit. Begriffe wie Datenbank oder UML kannst du daher voraussetzen. Erläutere die Fachbegriffe deiner Branche und betriebliche Besonderheiten so, dass eine betriebsfremde Person das Problem versteht. Beim Begriff "Vertrag" solltest du beispielsweise deutlich machen, welche Art von Vertrag gemeint ist.

Ausgangslage und Projektziel

Beschreibe in der Ist-Analyse, wie der bisherige Prozess abläuft und wo seine Schwachstellen liegen. Dazu können viele Excel-Dateien und Medienbrüche gehören. Auch bei einer neuen Anwendung braucht dein Antrag einen nachvollziehbaren Grund dafür,...

In der vierundzwanzigsten Episode des Anwendungsentwickler-Podcasts gebe ich Tipps zur Themenfindung für das Abschlussprojekt. Ich erläutere, worauf man achten sollte, und wie ich mit meinen eigenen Azubis Themen suche.

TL;DR

Ich empfehle dir, etwa sechs Monate vor dem Ausbildungsende mehrere Themen für dein Abschlussprojekt zu sammeln und sie mit deinem/deiner Ausbilder:in zu prüfen. Ideen findest du etwa im Ticketsystem, im Gespräch mit Kolleg:innen oder bei Aufgaben, die du täglich erledigst. Ein geeignetes Thema interessiert dich, lässt sich knapp erklären und passt zum Zeitrahmen der IHK. Schon vor dem Projektantrag solltest du den Ablauf durchplanen und klären, wie du den wirtschaftlichen Vorteil sowie deine fachlichen Methoden nachvollziehbar dokumentierst.

Kapitelmarken

[00:00:00] Hinweis zur Projektdokumentation

[00:00:36] Themenwahl für das Abschlussprojekt

[00:02:00] Früh anfangen und mehrere Themen sammeln

[00:04:36] Den Projektablauf vor dem Antrag planen

[00:05:36] Eigenständig suchen und mit dem/der Ausbilder:in entscheiden

[00:09:01] Projektideen aus dem Anforderungsmanagement

[00:10:19] Offene Aufgaben im Ticketsystem finden

[00:11:18] Kolleg:innen nach Problemen fragen

[00:12:06] Vorgesetzte nach Aufgaben fragen

[00:12:53] Wünsche aus dem Fachbereich und von Kund:innen

[00:14:13] Anregungen von anderen IT-Azubis und Mitschüler:innen

[00:15:33] Eigene Aufgaben verbessern und automatisieren

[00:17:13] In Gesprächen auf Projektideen achten

[00:17:53] Zusätzliche Themen vom/von der Ausbilder:in

[00:18:45] Mögliche Projektthemen bewerten

[00:19:07] Bisherige Erfahrungen und neue Themen berücksichtigen

[00:20:27] Das Projekt nach der Ausbildung fortführen

[00:21:02] Ein Thema wählen, das dich interessiert

[00:21:40] Das Thema knapp und verständlich erklären

[00:22:45] Erreichbare Ansprechpartner:innen einplanen

[00:23:42] Unterstützung im Unternehmen sichern

[00:24:29] Zeitrahmen und IHK-Termine prüfen

[00:26:01] Benötigte Komponenten und Aufwand abschätzen

[00:27:12] Fachliche Methoden in der Dokumentation zeigen

[00:29:18] Kenntnisse der benötigten Technologien prüfen

[00:30:08] Den wirtschaftlichen Vorteil belegen

[00:31:47] Zeitgemäße Technologien auswählen

[00:33:10] Firmengeheimnisse und offenlegbare Inhalte

[00:35:36] Kontakt und Shownotes

[00:36:40] Rezensionen und Newsletter mit Checklisten

Inhalt

Mit dem IHK-Abschlussprojekt beschäftigen sich die Azubis eine ziemlich lange Zeit und ein Großteil ihrer Abschlussnote hängt davon ab.

Mit Projektdokumentation und Projektpräsentation liegt ein großer Teil der Note in der eigenen Hand.

Daher sollte das Projektthema gut gewählt werden und vor allem auch Spaß machen.

Dennoch sind bei der Auswahl des Themas auch die Anforderungen der IHK zu beachten.

Allgemeine Tipps zur Themenfindung

Früh anfangen (6 Monate vorher)!

Projektablauf muss mit Erstellung des Projektantrags quasi feststehen.

Azubi sollte sich das Thema selbst suchen (Motivation).

Mehrere Themen suchen (Brainstorming) und anschließend gemeinsam mit Ausbilder bewerten.

Ausbilder sollte eine Liste mit möglichen Themen führen, für den Fall, dass der Azubi kein Thema findet.

Mögliche Quellen für Projektthemen

Anforderungsmanagement fragen

Ticket-System durchsuchen

Kollegen fragen

Vorgesetzten fragen

Fachbereich/Kunden interviewen

mit Mitazubis oder Mitschülern sprechen

eigene Aufgaben hinterfragen

in Besprechungen die Ohren aufhalten

Ausbilder fragen

Bewertung der potentiellen Projektthemen

Passt das Thema zum bisherigen Aufgabenbereich während der Ausbildung?

Kann das Thema evtl. nach Beendigung der Ausbildung fortgeführt werden?

Ist das Thema spannend für den Azubi?

Ist das Projektthema leicht zu erklären?

Sind die Ansprechpartner klar und stehen zur Verfügung?

Hat das Projekt Rückendeckung von Ausbilder und Unternehmen?

Passt der vorgegebene Zeitrahmen und der Durchführungszeitraum zu den IHK-Vorgaben?

Welche Komponenten (DB, Logik, GUI) werden benötigt?

Welche Methoden werden abgedeckt?

Sind alle benötigten Technologien bekannt?

Ist das Projekt wirtschaftlich?

Wird der aktuelle Stand der Technik verwendet?

Enthält das Projekt Firmengeheimnisse?

Literaturempfehlungen

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Aufbau und Ablauf der Abschlussprüfung - Anwendungsentwickler-Podcast #1

Zusammenfassung

Früh nach einem Thema suchen

Ich empfehle dir, etwa ein halbes Jahr vor dem Ausbildungsende gezielt nach einem Thema zu suchen. Bereits ab dem zweiten Ausbildungsjahr kannst du Aufgaben sammeln, die sich später als Abschlussprojekt eignen. Eine Liste mit beispielsweise zehn Ideen gibt dir Spielraum, ein Thema auszuwählen, das dich interessiert und zu den Anforderungen der IHK passt.

Im hier beschriebenen Prüfungsrahmen machen Projektdokumentation und Präsentation zusammen 75 Prozent der Note von Teil A aus. Beide kannst du selbst vorbereiten und vorab gegenlesen lassen. Deshalb lohnt es sich, Zeit für die Themenwahl einzuplanen.

Das Thema selbst finden und gemeinsam prüfen

Wenn du dein Thema selbst findest, stärkt das deine Motivation und gehört bereits dazu, ein Projekt eigenständig anzugehen. Besprich deine Liste anschließend mit deinem/deiner Ausbilder:in. Die Erfahrung mit den IHK-Anforderungen hilft dir dabei, den Umfang einzuschätzen und passende Methoden einzuplanen.

Für meine IT-Azubis halte ich zusätzlich fünf bis sechs Themen bereit, falls bei der eigenen Suche etwas Passendes fehlt. Dein:e Ausbilder:in kann dich auf diese Weise unterstützen, während du selbst nach möglichen Aufgaben suchst.

Den Ablauf vor dem Antrag durchdenken

Bevor du den Projektantrag abgibst, solltest du alle Projektphasen durchgeplant haben:

Welche Anforderungen musst du analysieren?

Wie entwirfst du die Lösung?

Was wirst du programmieren?

Wie testest du die Anwendung?

Wie sicherst du die Qualität?

Der Prüfungsausschuss braucht genügend konkrete Angaben, um das Thema beurteilen zu können. Für einen sorgfältigen Antrag einschließlich der Gespräche mit den Beteiligten solltest du mindestens ein bis zwei Tage einplanen.

Wo du Projektideen findest

Anforderungsmanagement: Frage die zuständige Person oder den/die Product Owner:in nach offenen Aufgaben. Anforderungen aus dem Fachbereich oder von Kund:innen haben häufig einen greifbaren wirtschaftlichen Vorteil.

Ticketsystem: Suche auch in älteren Tickets nach unerfüllten Wünschen und Problemen. Dort stehen oft Aufgaben, für die bisher die Zeit gefehlt hat.

Kolleg:innen: Frage im Fachbereich oder bei Entwickler:innen und Administrator:innen nach aufwendigen manuellen Tätigkeiten. Wenn du solche Abläufe automatisierst, lassen sich Zeitersparnisse häufig gut berechnen.

Vorgesetzte: Dein:e Vorgesetzte:r kennt möglicherweise Projekte, die schon länger umgesetzt werden sollen, und kann dir eine passende Aufgabe vorschlagen.

Fachbereich und Kund:innen: Direkte Gespräche bringen Wünsche zum Vorschein, die bisher keinen offiziellen Weg in die IT gefunden haben. Frage danach, welche Arbeitsschritte Schwierigkeiten machen.

Andere IT-Azubis und Mitschüler:innen: Ihre Projekte können dich auf andere Plattformen oder Themen bringen. Auch Erfahrungen aus älteren Ausbildungsjahrgängen helfen bei der Suche.

Deine eigenen Aufgaben: Prüfe, welche Tätigkeiten du häufig wiederholst. Beispiele sind das manuelle Aktualisieren einer Website oder eine gemeinsam bearbeitete Excel-Datei, bei der sich Kolleg:innen gegenseitig blockieren. Daraus kann eine datenbankgestützte Anwendung entstehen.

Besprechungen und beiläufige Gespräche: Achte darauf, wenn jemand von ungelösten Problemen oder lange aufgeschobenen Aufgaben erzählt.

Dein:e Ausbilder:in: Frage nach zusätzlichen Vorschlägen, wenn du deine eigenen Quellen durchgegangen bist oder weitere Alternativen prüfen möchtest.

Wie du mögliche Themen prüfst

Interesse und beruflicher Bezug

Prüfe bei jedem Thema, ob du dich mehrere Wochen damit beschäftigen möchtest. Wenn es eine Aufgabe betrifft, die dich selbst im Alltag stört, hast du einen konkreten Anreiz, sie zu verbessern.

Berücksichtige außerdem deine bisherigen Erfahrungen und die Zeit, die du zum Lernen brauchst. Vertraute Sprachen und Plattformen erleichtern es dir, den Aufwand einzuschätzen. Für eine neue Technologie musst du vor dem Projektbeginn genügend Zeit zum Einarbeiten vorsehen. Vor dem Antrag solltest du beurteilen können, ob du die nötigen Kenntnisse rechtzeitig erwerben kannst.

Ein Projekt kann außerdem den Einstieg in einen Aufgabenbereich vorbereiten, in dem du nach deiner Ausbildung arbeiten möchtest.

Verständlich erklären und Unterstützung sichern

Für betriebsfremde Prüfer:innen solltest du das Thema auf etwa einer halben bis einer Seite erklären können. Ausführliche fachliche Vorarbeiten beanspruchen Platz in der Dokumentation und Zeit in der Präsentation, die du für technische Inhalte brauchst.

Kläre früh, wer deine Fragen beantworten kann und wann diese Personen erreichbar sind. Häufige Rückfragen während des Projekts erfordern verlässliche Ansprechpartner:innen. Vereinbare auch mit deinem/deiner Ausbilder:in und dem Unternehmen, dass sie hinter dem Projekt stehen und dich bei Fragen unterstützen.

Umfang und Termine einschätzen

Der hier beschriebene Zeitrahmen beträgt 70 Stunden. Plane sämtliche benötigten Komponenten ein, einschließlich zusätzlicher Infrastruktur. Dazu können gehören:

eine Datenbank,

die fachliche Logik,

eine Oberfläche,

externe Services,

ein Build-Server.

Eine überschaubare datenbankgestützte Anwendung mit Oberfläche bietet häufig einen gut planbaren Umfang. Bei umfangreichen Systemen oder komplexer Logik steigt der Aufwand. Eine einzelne, einfache Teilaufgabe kann wiederum zu wenig fachlichen Inhalt bieten.

Die Arbeit muss außerdem in den Durchführungszeitraum der IHK passen. Beginnen darfst du nach dem beschriebenen Ablauf erst, wenn der Antrag genehmigt ist. Plane Spielraum ein, falls Auflagen einen überarbeiteten Antrag erforderlich machen. Ein flexibler Fertigstellungstermin erleichtert d