IT-Berufe-Podcast Archiv

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 mail@anwendungsentwicklerpodcast.de. 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 mail@anwendungsentwicklerpodcast.de 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

In der dreiundzwanzigsten Episode meines Anwendungsentwickler-Podcasts ergänze ich meine Empfehlungen zur Informationsbeschaffung um kostenpflichtige Quellen. TL;DR Ich empfehle dir kostenpflichtige Informationsquellen, mit denen du als IT-Azubi dein Fachwissen vertiefen und aktuelle Entwicklungen verfolgen kannst. Fachzeitschriften und Bücher ergänzen die Informationen aus dem Internet; Hörbücher und Online-Kurse bieten dir weitere Wege zum Lernen. Auch Gespräche in der Berufsschule oder Hochschule sowie Konferenzen geben dir Einblicke in die Praxis. Wenn dein Ausbildungsbetrieb Bücher oder Abos bezahlt, profitieren auch deine Kolleg:innen davon. Bei vielen Fachbüchern sparst du mit E-Books Geld, sodass sich ein E-Book-Reader nach einigen Käufen bezahlt machen kann. Kapitelmarken [00:00:01] Kostenpflichtige Informationsquellen für IT-Azubis [00:01:04] Fachbücher und Abos vom Ausbildungsbetrieb bezahlen lassen [00:04:26] Mit E-Books und einem E-Book-Reader Geld sparen [00:07:16] Internet und gedruckte Fachmedien ergänzen sich [00:08:52] c’t und iX für allgemeine und professionelle IT [00:11:12] Entwickler Magazin und OBJEKTspektrum [00:12:31] Fachzeitschriften für .NET und Java [00:14:32] Fachbücher und Early-Access-Ausgaben [00:16:20] Kommende Bücher als Hinweis auf Technologietrends [00:17:04] Empfehlungen für Fachbuchverlage [00:19:03] Günstigere Beta-Versionen von Büchern [00:19:46] Hörbücher und Audible [00:22:03] Informationen aus Berufsschule und Hochschule [00:23:05] Alte IHK-Prüfungen als Informationsquelle [00:24:43] Online-Kurse und Pluralsight [00:27:05] Konferenzen besuchen und Kontakte knüpfen [00:28:37] Kosten und Unterstützung durch den Betrieb [00:29:14] Weitere Empfehlungen und Shownotes [00:29:55] Kontakt und Feedback [00:30:40] Newsletter und Checklisten Inhalt Kostenpflichtige Informationsquellen Wem die Informationsquellen zu teuer sind, der sollte einmal sein Ausbildungsunternehmen fragen, ob die Kosten vielleicht übernommen werden. Wer viel liest, sollte sich überlegen, einen eBook-Reader anzuschaffen. Ich selbst nutze den günstigsten Kindle*. Er rentiert sich ggfs. bereits nach wenigen Büchern (Beispiel: POODR* kostet ca. 20 EUR anstatt 30 EUR als Taschenbuch). Zeitschriften c't* (Website) iX* (Website) Entwickler Magazin OBJEKTspektrum dotnetpro (.NET) Java Magazin (Java) JavaSPEKTRUM (Java) Bücher Viele Verlage bieten ein "Early Access"-Programm an. Dabei bekommt man neue Bücher schon (teils einige Monate) vor der Veröffentlichung. Pragmatic Programmers Manning O'Reilly Rheinwerk* Audiobooks Berufsschule/Studium IHK-Prüfungen Online-Kurse Pluralsight Vorlesungen online Konferenzen cim lingen Java-Forum-Nord NDC Oslo Øredev Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Smells like Java - Softwareentwicklung mit Natural (Artikel von mir im JavaSPEKTRUM) Zusammenfassung Kosten im Rahmen halten Frag dein:e Ausbilder:in, ob dein Ausbildungsbetrieb Fachbücher oder Zeitschriftenabos bezahlt. In meinem Unternehmen stehen regelmäßig angeschaffte Bücher in einer gemeinsamen EDV-Bibliothek, auf die auch Kolleg:innen zugreifen können. Dazu gehören beispielsweise die Java-Insel und Refactoring. In einer Abschlussprüfung habe ich außerdem eine Bibliotheks-App gesehen, die ein:e Prüfungsteilnehmer:in für die Büchersammlung des eigenen Unternehmens entwickelt hatte. Für ein Fachbuch fallen beispielsweise 50 bis 60 Euro an; eine einwöchige Schulung beim Softwareanbieter kann 3.000 bis 4.000 Euro kosten. Beim Lernen aus einem Buch spielen andere Bedingungen eine Rolle als bei einer Schulung. Über eine gemeinsame Bibliothek kann sich jedoch jede interessierte Person mit dem Thema beschäftigen. Auch Zeitschriften, die regelmäßig im Betrieb ausliegen, helfen dabei, fachlich auf dem Laufenden zu bleiben. Wenn du viele Fachbücher liest, rechne durch, ob sich ein E-Book-Reader für dich lohnt. Mein damals günstigster Kindle kostete etwa 60 Euro. Weil E-Books teilweise 10 bis 20 Euro günstiger waren als gedruckte Bücher, hatte ich die Kosten nach ungefähr fünf oder sechs Büchern wieder eingespart. Bei E-Books entfallen Möglichkeiten wie das gewöhnliche Verleihen eines gedruckten Buches. Dafür kann ich auf meinem Kindle Textstellen markieren und Notizen exportieren. Mit einem selbst geschriebenen Ruby-Skript übertrage ich diese Einträge in mein persönliches Wiki, sodass ich unterwegs darauf zugreifen kann. Für dich kommen auch andere E-Book-Reader infrage. Fachzeitschriften Wenn du aktuelle Meldungen im Internet verfolgst, kannst du sie durch ausführlich recherchierte Artikel aus Zeitschriften ergänzen. Durch die Zeit bis zum Druck erscheinen Nachrichten dort später. Längere Fachartikel und Anleitungen liefern dir Hintergrundwissen, während du mit einem Buch tiefer in ein Thema einsteigen kannst. Für die Ausbildung empfehle ich dir folgende Zeitschriften: c’t: Meine erste Empfehlung für IT-Azubis. Die Artikel decken viele IT-Bereiche ab, etwa Hardware und Betriebssysteme. Auch Softwareentwicklung gehört dazu. Ich empfehle die c’t ab dem ersten Ausbildungstag und habe sie im Unternehmen abonniert. iX: Behandelt professionelle IT und Themen aus dem Unternehmensumfeld. Nach ein bis zwei Jahren, wenn du dort Erfahrung gesammelt hast, empfehle ich dir einen Blick hinein. Entwickler Magazin: Enthält verständliche Artikel für Einsteiger:innen zu verschiedenen Programmiersprachen sowie Grundlagen der Softwareentwicklung. Eine Artikelserie zu Datenbanken und SQL verwende ich in meinen Schulungen. OBJEKTspektrum: Geht tiefer ins Softwareengineering, beispielsweise mit Artikeln zu Prozessanalyse oder Test-driven Development. dotnetpro: Meine Empfehlung, wenn du mit .NET arbeitest. Die Artikel enthalten ausführliche Beispiele und stammen von erfahrenen Autor:innen. Mit fast 15 Euro pro Ausgabe war die Zeitschrift zum Zeitpunkt meiner Aufnahme vergleichsweise teuer. Java Magazin: Bietet praxisbezogene Artikel für Java-Entwickler:innen. JavaSPEKTRUM: Greift auch Themen aus dem akademischen Umfeld auf und ist ebenfalls für Java geeignet. Für weitere Sprachen gibt es eigene Publikationen, etwa das PHP Magazin. Meine konkreten Empfehlungen konzentrieren sich auf Java und .NET, weil ich diese Bereiche kenne. Fachbücher und frühe E-Book-Ausgaben Wenn du dich länger mit einer Programmiersprache oder einem Framework beschäftigen möchtest, sind Fachbücher für mich die wichtigste Quelle. Bis eine gedruckte Ausgabe erscheint, können mehrere Monate vergehen. Einige Verlage bieten deshalb Beta- oder Early-Access-Ausgaben als E-Book an, die du schon vor dem gedruckten Buch lesen kannst. Bei den Pragmatic Programmers habe ich mehrfach solche Vorabversionen gelesen. Sie waren Wochen oder Monate früher verfügbar und sind teilweise günstiger. Gelegentliche Tippfehler gehören bei diesen Ausgaben dazu. Lesen kannst du sie auf einem E-Book-Reader, einem Tablet oder am Bildschirm. Diese Verlage empfehle ich dir: Pragmatic Programmers: Praxisorientierte Bücher, auch zu neueren Sprachen. Beispiele aus meinem Umfeld sind Ruby und Elixir. Manning: Ausführliche Bücher zu modernen Technologien. O’Reilly: Fachbücher rund um IT und Softwareentwicklung, häufig von bekannten Autor:innen. Der Verlag bietet auch ein Early-Release-Programm an. Rheinwerk Verlag, früher Galileo Press: Deutschsprachige Fachbücher, darunter das IT-Handbuch für Fachinformatiker:innen und die Java-Insel. Einige Bücher stehen als Open Book online zur Verfügung. Auf den Verlagsseiten schaue ich regelmäßig nach kommenden Büchern. Die behandelten Themen geben Hinweise darauf, welche Technologien gerade Interesse wecken, auch wenn du selbst kein Buch dazu kaufst. Hörbücher Auf dem Weg zur Arbeit oder beim Sport kannst du Hörbücher hören und so Zeit für Fachinhalte finden. Ich greife darauf zurück, wenn mir die Zeit zum Lesen fehlt. Mit etwas Übung lässt sich die Wiedergabegeschwindigkeit erhöhen; im Podcast beschreibe ich das Hören mit doppelter oder dreifacher Geschwindigkeit. Bei Audible gibt es ein monatliches Abo, über das du eine bestimmte Anzahl von Hörbüchern beziehen kannst. Zum Angebot gehören aktuelle Bücher, die teilweise von den Autor:innen selbst vorgelesen werden. Berufsschule, Hochschule und IHK-Prüfungen Frag deine Lehrer:innen oder Dozent:innen nach den Technologien, mit denen sie arbeiten, und nach Entwicklungen, die sie verfolgen. Ich empfehle dir, diese Gespräche gezielt zu suchen. Berufsschule und Studium kosten Zeit; je nach Angebot fallen auch Gebühren an oder dein Unternehmen trägt Kosten. Für deine Prüfung kannst du alte IHK-Aufgaben kaufen. Im Podcast nenne ich dafür ungefähr zehn Euro pro Prüfung. An den Aufgaben erkennst du, welches Wissen die Prüfer:innen erwarten. Neue Technologien gelangen mit zeitlichem Abstand in die Prüfungen. Zum Zeitpunkt meiner Aufnahme beobachtete ich aktuellere Themen vor allem in der Systemintegration. In der Anwendungsentwicklung kamen seit Jahren ähnliche Inhalte vor, etwa UML und Programmieren auf Papier. Wenn weitere Technologien in Aufgaben auftauchen, gibt dir das einen Anlass, dich auch im Berufsalltag damit zu beschäftigen. Online-Kurse Wenn du anderen Entwickler:innen beim Programmieren zuschauen möchtest, bieten dir Online-Kurse dafür einen passenden Rahmen. Über Videos kannst du Arbeitsschritte verfolgen und dich geführt mit einem Thema beschäftigen. Ich bin selbst Kunde bei Pluralsight und empfehle dir die Plattform aus eigener Erfahrung. Dort unterrichten bekannte Entwickler:innen aus unterschiedlichen Technologiebereichen. Tests helfen dir dabei, zu prüfen, ob du die Inhalte verstanden hast. Als weiteren Anbieter erwähne ich lynda.com, mit dem ich selbst keine Erfahrung habe. Kostenlose Konferenzvideos auf YouTube oder Vimeo ergänzen solche Angebote. Ihr Format ist auf einen Vortrag ausgelegt, während ein Online-Kurs ein Thema als Unterricht aufbereitet. Konferenzen Wenn dein Unternehmen eine Konferenz bezahlt,...

In der zweiundzwanzigsten Episode meines Anwendungsentwickler-Podcasts gebe ich eine Übersicht guter kostenloser Informationsquellen rund um die Ausbildungsinhalte, mit denen man als ITler auf dem Laufenden bleibt. TL;DR Mit den kostenlosen Quellen, die ich dir empfehle, bleibst du als IT-Azubi und nach deiner Ausbildung fachlich auf dem Laufenden. Auf Websites und in Podcasts findest du aktuelle IT-Themen, während Konferenzvideos und kostenlose E-Books dir helfen, tiefer einzusteigen. Über Feeds oder Newsletter bekommst du neue Beiträge automatisch; im Gespräch mit deinem/deiner Ausbilder:in und anderen IT-Interessierten lernst du weitere Perspektiven kennen. Plane außerdem Zeit ein, um neue Technologien selbst auszuprobieren und einzuschätzen, wie sie zu deiner Arbeit passen. Kapitelmarken [00:00:20] Kostenlose Quellen für IT-Azubis und die Zeit danach [00:02:18] IT-Nachrichten auf Websites [00:03:58] Blogs von Softwareentwickler:innen [00:05:22] RSS, Atom und Feedreader [00:06:48] Reddit und Social Bookmarks [00:08:40] Fachforen und fachinformatiker.de [00:10:06] Neue Beiträge über Feeds und Newsletter erhalten [00:10:47] Podcasts finden und abonnieren [00:12:57] Kostenlose Konferenzvideos [00:14:28] E-Books und online verfügbare Fachbücher [00:15:43] Von Ausbilder:innen und Kolleg:innen lernen [00:18:02] Mit anderen IT-Azubis und Mitschüler:innen sprechen [00:18:41] Regionale Treffen und einen eigenen Stammtisch organisieren [00:20:11] Gelegenheiten für persönliche Gespräche schaffen [00:21:00] Twitter und berufliche Kontakte in sozialen Netzwerken [00:24:23] Neue Technologien selbst ausprobieren [00:26:26] Zeit zum Ausprobieren einplanen [00:26:58] Shownotes und weitere Quellen empfehlen [00:28:06] Feedback und Themenwünsche [00:29:02] Mein Newsletter und Checklisten für das Abschlussprojekt Inhalt Kostenlose Informationsquellen Websites News Blogs Aggregatoren Social Bookmarks Foren Lernplattformen Auf dem Laufenden bleiben: Newsletter oder Feed abonnieren. Podcasts Auf dem Laufenden bleiben: In iTunes oder im Podcatcher* abonnieren. Konferenzvideos Auf dem Laufenden bleiben: Feeds abonnieren, auf Twitter folgen, bei YouTube/Vimeo abonnieren usw. eBooks Auf dem Laufenden bleiben: Newsletter abonnieren oder Neuheiten regelmäßig checken. Andere ITler Ausbilder/in Kollegen (auch aus anderen Abteilungen) Mitazubis Klassenkameraden Lokale Events, Veranstaltungen von Hochschulen, User Groups, Code Retreat, Barcamps Auf dem Laufenden bleiben: An Veranstaltungen teilnehmen, gemeinsam Mittagessen, um Zeit für Gespräch bitten, regelmäßige Meetings einberufen usw. Soziale Netzwerke Twitter Xing Facebook Auf dem Laufenden bleiben: Die jeweilige App des Netzwerks, Bookmarks auf Timeline setzen und regelmäßig abrufen. Selbst neue Technologien ausprobieren Programmiersprachen Tools Betriebssysteme Auf dem Laufenden bleiben: Zeit für Ausprobieren einplanen. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Tools Tiny Tiny RSS BeyondPod* RSSOwl Websites News heise.de neuerdings.com Blogs IT-Pro Bloggers DotNetGerman Bloggers (.NET) Werd Fachinformatiker Aggregatoren Subreddit: programming The Morning Brew (.NET) Social Bookmarks Delicious Foren Fachinformatiker ausbilden Fachinformatiker.de Prüfungsfragen Lernplattformen Codecademy Konferenzvideos InfoQ Confreaks (Ruby) MSDN Techwiese (.NET) JAXenter (Java) eBooks Rheinwerk* Google Books Andere ITler Softwareentwickler-Stammtisch Diepholzer Kolloquium Gesellschaft für Informatik, Regionalgruppe Bremen Oldenburg Global Day of Coderetreat Soziale Netzwerke Stefan Macke bei Twitter Xing-Gruppe Softwareentwicklung im Raum Oldenburger Münsterland Xing-Gruppe Fachinformatiker Systemintegration und Anwendungsentwicklung Xing-Gruppe Softwareentwickler Zusammenfassung Websites und aktuelle Beiträge Für aktuelle IT-Nachrichten schaue ich täglich auf heise.de vorbei. Hinter der Website steht der Verlag, der auch c’t und iX herausgibt. Dort bekommst du einen Überblick darüber, was sich im IT-Bereich gerade bewegt. Wenn du dich genauer mit einer Technologie beschäftigen möchtest, findest du in den Blogs von Softwareentwickler:innen ausführliche Artikel direkt von den Menschen, die daran arbeiten. Wähle Blogs passend zu deinem Arbeitsgebiet und deinen Interessen aus. Als .NET-Entwickler:in kannst du beispielsweise den entsprechenden Fachleuten folgen und zusätzlich Einblicke in andere Programmiersprachen sammeln. Neue Beiträge automatisch erhalten In meinem Feedreader abonniere ich die Quellen, die mich interessieren. Dafür gibt es die XML-basierten Formate RSS und Atom, über die Websites ihre Beiträge bereitstellen. RSS steht für "Really Simple Syndication". Ein Feedreader zeigt dir neue Artikel an, sobald sie im abonnierten Feed erscheinen. Solche Programme gibt es online und offline. Den passenden Feed findest du häufig über ein orangefarbenes Symbol, das an ein Funksignal erinnert. Auch Foren und andere Websites bieten Feeds an. Newsletter schicken dir neue Informationen direkt per E-Mail, wobei du deine E-Mail-Adresse angeben musst. Themen über Empfehlungen entdecken Bei Reddit schaue ich morgens nach neuen Beiträgen zur Programmierung. Dort stellen Nutzer:innen Links ein und bewerten sie. Hoch bewertete Beiträge geben Hinweise darauf, welche Themen gerade viele Menschen beschäftigen. Über Subreddits kannst du die Themen auswählen, die dich interessieren, und dabei auf Beiträge aus unterschiedlichen Bereichen der Softwareentwicklung stoßen. Mit Social Bookmarks, etwa bei Delicious, teilen Menschen ihre gespeicherten Links öffentlich. An der Zahl der gespeicherten Lesezeichen lässt sich erkennen, welche Inhalte häufig gelesen werden. Fragen in Foren stellen In einem Forum kannst du eigene Fragen stellen und mit anderen Mitgliedern diskutieren. Suche nach einem Forum, das zu deinen Technologien oder Interessen passt, beispielsweise zu Java oder .NET. Für die Ausbildung empfehle ich fachinformatiker.de. Dort findest du Themen rund um die Ausbildung und Fragen zu Prüfungen. Auch einzelne IT-Themen und Programmiersprachen werden behandelt. Podcasts im Alltag hören Auf meinem Arbeitsweg höre ich abonnierte Podcasts, deren neue Folgen meine App automatisch herunterlädt. Mit BeyondPod auf meinem Android-Handy lasse ich sie morgens aktualisieren. Du kannst Podcasts etwa beim Sport hören oder während du Hausarbeiten erledigst. Für viele Programmiersprachen gibt es eigene Angebote. In längeren Folgen können Entwickler:innen ausführlich über aktuelle Themen und neue Frameworks sprechen, beispielsweise bei Ruby Rogues. Nach passenden Podcasts kannst du in Verzeichnissen wie Podcast.de suchen. Auch iTunes und Stitcher werden als Anlaufstellen genannt. Durch ein Abo erhältst du neue Folgen automatisch. Konferenzvideos kostenlos ansehen Über Videos von Entwicklerkonferenzen kannst du Vorträge online verfolgen. Viele Konferenzen stellen ihre Aufzeichnungen kostenlos bereit, sodass du dir aktuelle Technologien anschauen kannst, ohne Eintritt für die Veranstaltung zu bezahlen. Als Beispiele nenne ich Ruby- und Rails-Konferenzen sowie NDC und Øredev. Auch von JAX beziehungsweise W-JAX und BASTA! gibt es Videos im Internet. Je nach Anbieter erfährst du über RSS-Feeds oder Twitter von neuen Aufzeichnungen. Auf YouTube und Vimeo kannst du entsprechende Kanäle abonnieren. In kostenlosen E-Books nachlesen Bei Google Books findest du teilweise vollständige Bücher, die du online lesen und im Volltext durchsuchen kannst. Schau dort nach, wenn du zu einem bestimmten Thema ein Buch suchst. Der Rheinwerk Verlag stellt einige Bücher vollständig online bereit, häufig in älteren Ausgaben. Dazu gehört auch das IT-Handbuch für Fachinformatiker:innen. Die Inhalte sind auf einzelne Webseiten verteilt, durch die du dich zum Nachschlagen klickst. Mit anderen Menschen sprechen Wenn ich einen passenden Artikel finde, gebe ich ihn an meine IT-Azubis weiter. Gerade zu Beginn deiner Ausbildung hilft dir dein:e Ausbilder:in dabei, geeignete Quellen zu finden und interessante Inhalte auszuwählen. Frage gezielt nach Leseempfehlungen oder bitte um Zeit für ein Gespräch über neue fachliche Themen. Mit Kolleg:innen aus deiner Entwicklungsabteilung kannst du über andere Programmiersprachen und Frameworks sprechen. So erfährst du auch, welche Technologien im Unternehmen gerade ausprobiert werden. Menschen aus anderen Abteilungen bringen weitere Perspektiven mit. In der Administration erhältst du beispielsweise andere IT-Einblicke; aus Fachabteilungen erfährst du etwas über betriebliche Abläufe oder wirtschaftliche Themen. Andere IT-Azubis und deine Mitschüler:innen können Quellen empfehlen und von ihren Erfahrungen erzählen. Wenn du studierst, gilt das auch für deine Kommiliton:innen. Bei regionalen User-Groups kannst du zuhören und mitdiskutieren. Auch Code-Retreats oder Barcamps bieten Gelegenheiten, IT-Interessierte kennenzulernen. Weil es in meiner ländlichen Umgebung wenige passende Gruppen gab, habe ich einen eigenen Softwareentwickler:innen-Stammtisch gegründet. Über eine solche Gruppe kannst du dich regelmäßig mit Menschen austauschen, die ähnliche Interessen haben. Gespräche ergeben sich auch beim gemeinsamen Mittagessen mit Kolleg:innen. Kontakte über soziale Netzwerke finden Auf Twitter verfolge ich kurze Hinweise und Links zu ausführlicheren Beiträgen. Von Konferenzen berichten Teilnehmer:innen zeitnah über Vorträge und teilen beispielsweise Fotos oder Links zu Folien. Du kannst dich selbst an diesen Gesprächen beteiligen. Über Gruppen auf Xing oder Facebook kommst du mit Menschen in Kontakt, die sich für ähnliche Themen interessieren. Für berufliche Kontakte empfehle ich Xing. Dort gibt es Gruppen für Fachinformatiker:innen und Softwareentwickler:innen, in denen du dich über Foren austauschen kannst. Für meinen Stammtisch habe ich eine Xing-Gruppe eingerichtet,...

In der einundzwanzigsten Episode meines Anwendungsentwickler-Podcasts gebe ich einige Tipps zum Berufseinstieg für neue Azubis. TL;DR Für deinen Ausbildungsstart als IT-Azubi empfehle ich dir, von Anfang an neugierig zu lernen und bei offenen Fragen nachzuhaken, damit du Aufgaben später selbstständig lösen kannst. Kläre früh die Regeln im Betrieb, führe dein Berichtsheft regelmäßig und arbeite in der Berufsschule mit, während du dich mit deinem Ausbildungsbetrieb und den IT-Grundlagen vertraut machst. Als angehende:r Fachinformatiker:in Anwendungsentwicklung lernst du, Probleme mit Software zu lösen; dabei helfen dir auch wiederkehrende Aufgaben, die du automatisierst, und passende Werkzeuge, die bereits vorhanden sind. Sobald du die Abläufe kennst, bring eigene Ideen ein und besprich sie mit deinem:r Ausbilder:in. Kapitelmarken [00:00:01] Einstieg und Themenüberblick [00:01:11] Lernen für die Prüfung und den Beruf [00:02:43] IT-Themen im Alltag entdecken [00:03:39] Nachfragen und Zusammenhänge verstehen [00:05:33] Besprechungen protokollieren [00:06:32] Betreuung einfordern und Abläufe hinterfragen [00:07:45] Durch Dokumentieren lernen [00:08:58] Fachbücher und das IT-Handbuch [00:10:37] Austausch mit anderen IT-Interessierten [00:12:22] Früh für die Abschlussprüfung lernen [00:13:20] Wissen im eigenen Blog festhalten [00:14:14] Arbeitszeiten und Urlaub klären [00:15:50] Das Berichtsheft regelmäßig führen [00:16:43] In der Berufsschule mitarbeiten [00:18:00] Kolleg:innen und Ausbilder:in kennenlernen [00:20:10] Produkte und Abläufe im Betrieb verstehen [00:21:18] IT-Grundlagen aufbauen [00:22:29] Office-Programme und Textverarbeitung beherrschen [00:23:45] Probleme mit Software lösen [00:25:32] Wiederkehrende Aufgaben automatisieren [00:26:40] Vorhandene Werkzeuge und Make-or-Buy [00:28:01] Eigene Ideen einbringen [00:29:49] Abläufe hinterfragen und Aufgaben selbst finden [00:30:46] Shownotes und Feedback [00:31:37] Den Podcast weiterempfehlen [00:32:03] Fragen zur Ausbildung stellen [00:32:20] Newsletter und Projektchecklisten Inhalt Ihr habt nur eine Aufgabe: Lernen. Seid neugierig. Haltet die Ohren offen. Fragt nach. Führt freiwillig Protokolle. Schreibt Dokumentationen. Lest Bücher*. Sucht Gleichgesinnte zum Erfahrungsaustausch (offline oder online). Bereitet euch so früh wie möglich auf die Abschlussprüfung vor. Startet ein Blog. Haltet notwendige Formalien ein. Klärt wichtige Rahmenbedingungen (Urlaub, Arbeitszeit usw.) gleich zu Beginn. Führt euer Berichtsheft von Anfang an regelmäßig. Beteiligt euch aktiv in der Berufsschule. Lernt euren Ausbildungsbetrieb kennen. Integriert euch von Anfang an in das Unternehmen. Nehmt alle Möglichkeiten wahr, eure Kollegen kennenzulernen. Sprecht regelmäßig mit eurem/r Ausbilder/in. Sprecht mit anderen Azubis über die Ausbildung. Geht offen auf eure neuen Kollegen zu und tauscht euch aus. Lernt die Produkte und Prozesse des Unternehmens kennen. Lernt zentrale IT-Grundlagen. Betriebssysteme Netzwerkinfrastruktur, Internet Office-Produkte Datenbanken HTML Lernt vernünftig zu programmieren. Lernt nicht eine Programmiersprache, sondern das Lösen von Problemen. Wenn ihr eine Sache zum zweiten Mal macht, automatisiert sie. Evaluiert und verwendet die besten Tools, die ihr findet könnt. Bringt eure eigenen Ideen ein. Haltet die Augen offen: Wo kann man Prozesse automatisieren? Hinterfragt Prozesse im Unternehmen. Werdet selbst aktiv, anstatt auf Aufgaben zu warten. Literaturempfehlungen Meine Empfehlung für alle Azubis. Gut geschrieben und mit über 1.000 Seiten sehr umfangreich. Alle für die Ausbildung relevanten Themen werden zumindest gestreift. Am besten direkt im ersten Ausbildungsjahr mit dem Lesen anfangen ;-) *(direkt beim Rheinwerk-Verlag bestellen*) Das Standardwerk, das alle Ausbildungsinhalte enthält. * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Meine Ausbildungsinhalte - Anwendungsentwickler-Podcast #3 How To Ask Questions The Smart Way Softwareentwickler-Stammtisch Fachinformatiker.de (Forum) Vorbereitung auf die schriftliche Abschlussprüfung - Anwendungsentwickler-Podcast #4 Tipps zum Berichtsheft Zusammenfassung Von Anfang an lernen und nachfragen Wenn du während der Ausbildung Wissen sammelst, bereitest du dich auf die Abschlussprüfung und auf deinen späteren Beruf vor. Nach der Ausbildung sollst du Projekte selbstständig bearbeiten können. Deshalb empfehle ich dir, auch außerhalb deines Fachgebiets Erfahrungen zu sammeln, etwa in der Netzwerkadministration oder im Kontakt mit Kund:innen. Ein Einblick in die Buchhaltung hilft dir, wirtschaftliche Zusammenhänge zu verstehen. Hör in Besprechungen und bei Gesprächen mit Kolleg:innen aufmerksam zu. Auch in der Berufsschule erfährst du, welche IT-Themen gerade beschäftigen. Unbekannte Begriffe kannst du dir aufschreiben und anschließend recherchieren. Wenn du eine Erklärung nicht verstehst, frag direkt nach. Gerade betriebsinterne Kürzel lassen sich oft nur im Gespräch klären. Erfahrene Kolleg:innen haben ihre Abläufe so verinnerlicht, dass sie einzelne Schritte beim Erklären übergehen. Durch deine Fragen erfahren sie, wo du Hilfe brauchst. Programmieren lernst du während der Ausbildung; dein Code sollte für dich nachvollziehbar sein. Von deinem Ausbildungsbetrieb kannst du erwarten, dass er Zeit für dich einplant und deine Fragen beantwortet. Fordere diese Hilfe aktiv ein. Falls du dauerhaft als billige Arbeitskraft eingesetzt wirst und beim Lernen alleinbleibst, empfehle ich dir, dich an die IHK zu wenden oder einen anderen Ausbildungsbetrieb zu suchen. Durch Schreiben genauer verstehen Beim Protokollieren einer Besprechung sammelst du Themen, mit denen du dich anschließend beschäftigen kannst. Recherchiere die Begriffe, die du aufgeschrieben hast, und kläre offene Punkte mit deinem:r Ausbilder:in. In den ersten Wochen prüfe ich solche Protokolle und frage nach, was der jeweilige Eintrag bedeutet. Wenn du ein Produkt oder eine selbst entwickelte Software dokumentierst, musst du die technischen Zusammenhänge so weit verstanden haben, dass du sie anderen erklären kannst. Biete an, eine solche Aufgabe zu übernehmen. Dabei gehst du die bisherige Arbeit noch einmal durch und übst zugleich für die Dokumentation deines Abschlussprojekts. Mit einem eigenen Blog kannst du festhalten, was du gelernt hast. Auch Beiträge in einem Forum oder Wiki helfen dir, dein Wissen verständlich zu formulieren. Ein Blog macht deine Arbeit zudem sichtbar und kann dir später beruflich helfen. Wenn du einen startest, kannst du mir den Link schicken; ich verlinke solche Blogs auf meiner Seite. Bücher lesen und Erfahrungen austauschen Für Themen, mit denen du dich ausführlich beschäftigen möchtest, empfehle ich dir Fachbücher. Sie behandeln Zusammenhänge über viele Seiten hinweg, etwa zu deiner Programmiersprache. Wähle gezielt Bücher zu Grundlagen und zu den Themen aus, die du brauchst. Das IT-Handbuch für Fachinformatiker:innen umfasst über 1.000 Seiten und behandelt die verschiedenen Bereiche der Ausbildung. Du kannst bereits zu Beginn regelmäßig darin lesen. Im Gespräch mit anderen IT-Azubis erfährst du, wie deren Ausbildung abläuft. Kolleg:innen und Lehrkräfte können dir fachlich weiterhelfen; online findest du Austausch in Foren und Blogs. Versuche bei recherchierbaren Problemen zunächst selbst, eine Antwort zu finden. Wenn du festhängst, frag nach. Bei meinem Softwareentwickler:innen-Stammtisch im Raum Oldenburg im Münsterland kannst du dich auch als IT-Azubi beteiligen. Dort geht es darum, in lockerer Atmosphäre über Softwarethemen zu sprechen. Deine Erfahrungen und dein Blick auf neue Entwicklungen können auch für erfahrene Entwickler:innen interessant sein. Früh für die Prüfung lernen und in der Berufsschule mitarbeiten Wenn du ab dem ersten Ausbildungstag regelmäßig lernst, verteilt sich der Stoff über die Ausbildungszeit. Das erleichtert dir später das Lernen für die Abschlussprüfung und hilft dir, Wissen langfristig zu behalten. Besprich mit deinem:r Ausbilder:in, welche Literatur geeignet ist und wie du dich gezielt vorbereitest. Arbeite auch in der Berufsschule von Anfang an mit. Dort kannst du fachliche Fragen mit Lehrkräften besprechen und prüfungsrelevante Inhalte üben. Gerade wenn du im Betrieb wenig betreut wirst, bietet dir der Unterricht Gelegenheit, fehlendes Wissen aufzubauen. Arbeitszeiten, Urlaub und Berichtsheft klären Sprich zu Beginn mit deinem:r Ausbilder:in über die Regeln, die deinen Arbeitsalltag betreffen: Kläre, welche Arbeitszeiten gelten und wann du bei Gleitzeit anwesend sein sollst. Dabei spielt auch eine Rolle, wann dein:e Ausbilder:in erreichbar ist. Frag nach, wie du Urlaub beantragst und mit wem du ihn abstimmen musst. Besprich auch, welche Regeln während der Probezeit gelten und wie eine Vertretung organisiert wird. Halte deine Tätigkeiten von Anfang an im Berichtsheft fest, beispielsweise jede Woche. Lass es regelmäßig kontrollieren und unterschreiben. Mit einem laufend geführten Berichtsheft sparst du dir das spätere Nachtragen. Es wird für die Prüfung gebraucht und hält fest, welche Aufgaben du während der Ausbildung übernommen hast. Bei Problemen mit dem Betrieb kannst du damit belegen, wie deine Ausbildung verlaufen ist. Den Ausbildungsbetrieb kennenlernen Geh auf Kolleg:innen aus anderen Abteilungen zu und lass dir zeigen, womit sie arbeiten. Wenn du ihre Aufgaben und Schwierigkeiten kennst, kannst du besser verstehen, wo IT ihnen hilft. Durch den persönlichen Kontakt wirst du als Ansprechpartner:in wahrgenommen. Mit deinem:r Ausbilder:in solltest du früh offen sprechen, weil diese Person deine Ausbildung begleitet. Andere IT-Azubis können dir erzählen, welche Erwartungen im Betrieb bestehen und was dich im weiteren Verlauf erwartet. Schau dir außerdem die Produkte deines Unternehmens an und lass dir die Abläufe erklären. Du solltest wissen, womit der Betrieb Geld verdient....

In der zwanzigsten Episode meines Anwendungsentwickler-Podcasts blicke ich auf die Abschlussprüfung im Sommer 2015 zurück und gebe Tipps für die kommenden Prüflinge. TL;DR Bei meinen 21 Prüfungen im Sommer 2015 fielen mir vor allem sprachliche Fehler und Lücken beim fachlichen Verständnis auf. Für deine Abschlussprüfung als Fachinformatiker:in Anwendungsentwicklung solltest du sorgfältig geprüfte Texte abgeben, dein methodisches Vorgehen sichtbar machen und zeigen, was du selbst entwickelt hast. Im Fachgespräch musst du deinen Code sowie die eingesetzten Technologien erklären und deine Entscheidungen begründen können. Wenn dein Betrieb dich fachlich kaum ausbildet, wende dich frühzeitig an die IHK. Kapitelmarken [00:00:01] Einstieg und Rückblick auf die Sommerprüfung 2015 [00:01:15] Schriftliche Prüfung: WiSo und Algorithmenaufgaben [00:03:23] Sprachliche Fehler in der Projektdokumentation [00:05:48] Rechtschreibung auf Präsentationsfolien [00:07:10] Methodisches Vorgehen bei der Softwareentwicklung [00:09:58] Eigene Arbeit und fachliche Tiefe im Abschlussprojekt [00:11:51] REST und JSON im Fachgespräch erklären [00:14:21] Programmiersprachen und Typisierung verstehen [00:16:21] Häufige Fachgesprächsfragen vorbereiten [00:18:39] Funktionale Sprachelemente und Generics [00:20:04] Eigenen Quelltext verstehen: using in C# [00:21:22] Technische Entscheidungen begründen [00:24:01] Präsentationen mit Bildern ansprechend gestalten [00:25:38] Mangelhafte betriebliche Ausbildung und Hilfe durch die IHK [00:29:41] Rückblick auf die wichtigsten Prüfungsprobleme [00:30:36] Shownotes und Kontaktmöglichkeiten [00:31:51] Newsletter und Checklisten für dein Abschlussprojekt Inhalt Die schriftliche Prüfung hat dieses Jahr viele Prüflinge ihre gute Note gekostet. Insb. WiSo hat viele Prüflinge runtergezogen. Die Rechtschreibprüfung und ein Korrekturleser sind die Freunde jedes Prüflings. Das gilt auch für die Projektpräsentationen. Methodik fehlt häufig in den Präsentationen und Dokumentationen. Wenige Zeilen Code reichen nicht als Abschlussprojekt. SAP-Projekte fallen auffällig oft in diesen Bereich. REST zusammen mit JSON kommt immer häufiger zum Einsatz. Leider kann fast niemand definieren, was das eigentlich ist. Das gleiche gilt für die zentralen Eigenschaften der eigenen Programmiersprache (z.B. Typisierung). Standardfragen können immer noch nicht beantwortet werden. Das reißt teils sogar gute Prüflinge rein. Funktionale Programmierung wird noch nicht angewendet. Programmierfeatures (wie z.B. Lambdas, Generics) werden eingesetzt, ohne sie zu verstehen. Die Frage nach dem "Warum" wird selten gestellt. Einige Vorgaben werden einfach hingenommen. Die Präsentationen werden langsam farbenfroher und ansprechender. Mehrere Prüflinge wurden von ihren Betrieben im Regen stehen gelassen. Wenn euch das auch so geht, macht euch frühzeitig Gedanken, was ihr dagegen tun könnt (z.B. bei der IHK melden). Literaturempfehlungen * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Die 17 häufigsten Fehler in der Projektdokumentation - Anwendungsentwickler-Podcast #9 Die 11 häufigsten Fehler in der Projektpräsentation - Anwendungsentwickler-Podcast #7 Mythen der Projektpräsentation (Blog-Artikelreihe) Representational State Transfer – Wikipedia JavaScript Object Notation – Wikipedia Zusammenfassung Schriftliche Sommerprüfung 2015 Bei meinen 21 Prüfungen im Sommer 2015 sah ich viele interessante Projekte, darunter auch solche mit modernen Technologien. Die schriftlichen Ergebnisse drückten bei vielen IT-Azubis die Abschlussnote, selbst wenn ihre Projektdokumentation und Präsentation gut ausfielen. WiSo: Viele Prüfungsteilnehmer:innen erreichten eine 3 oder schlechter. Dieser Bereich machte damals 20 Prozent von Teil B aus und konnte die Gesamtnote an einer Notengrenze verschieben. Als mögliche Ursache fielen Fragen auf, die in den Prüfungen der vorherigen Jahre kaum vorkamen. Meine bisherige Empfehlung, die Aufgaben der letzten fünf Jahre auswendig zu lernen, reichte in dieser Prüfung für viele kaum aus. Ganzheitliche Aufgabe 1: Zwei umfangreiche Aufgaben verlangten Algorithmen in Pseudocode. Auch nach dem Streichen einer Aufgabe blieb eine größere Programmieraufgabe übrig. Wegen des hohen Zeitbedarfs empfehle ich bei solchen Aufgaben, sorgfältig abzuwägen, welche du streichst. Vielen Prüfungsteilnehmer:innen fehlte anschließend Zeit für weitere Aufgaben. Texte und Folien sorgfältig prüfen Beim Lesen der Projektdokumentationen begegneten mir Fehler, durch die einzelne Sätze kaum verständlich waren. Teilweise fehlten Wörter oder Kommas; auch offensichtliche Schreibfehler standen schon in den ersten Sätzen. Aktiviere die Rechtschreibprüfung deiner Software und korrigiere die markierten Stellen. Word bietet diese Funktion, ebenso lässt sie sich in Eclipse einschalten, wenn du dort mit LaTeX arbeitest. Ich empfehle LaTeX für die Projektdokumentation und stelle auf meiner Website eine Vorlage bereit. Für verständliche Inhalte brauchst du zusätzlich jemanden, der deinen Text gegenliest, etwa dein:e Ausbilder:in oder eine Person aus deiner Familie. Dabei lassen sich unklare Sätze und schwer nachvollziehbare Inhalte entdecken. Auch deine Präsentationsfolien solltest du mehrfach durchlesen. PowerPoint hat ebenfalls eine Rechtschreibprüfung. Fehler in gewöhnlichen deutschen Wörtern fallen Prüfer:innen schnell auf. Bei mir führen solche Fehler dazu, dass ich auch den Code genauer prüfe. Dein Vorgehen bei der Softwareentwicklung zeigen Vor dem Programmieren solltest du klären, was die Anwender:innen brauchen und wie du die Software aufbauen möchtest. In einigen Prüfungsprojekten blieb dieses Vorgehen kaum erkennbar, weil die Dokumentation vor allem allgemeine Beschreibungen oder Quelltext enthielt. Je nach Projekt kannst du deine Überlegungen mit folgenden Mitteln sichtbar machen: Use Cases sowie einem Lastenheft oder Pflichtenheft, um die Anforderungen festzuhalten. Anwendungsfalldiagrammen und Klassendiagrammen, die deine Software beschreiben. ER-Modellen für die Datenbank. Aktivitätsdiagrammen oder EPKs für Abläufe und Prozesse. Zu einem fachlich durchdachten Projekt gehören außerdem Tests und Maßnahmen, mit denen du die Qualität prüfst. Auch im damals vorgesehenen 70-Stunden-Projekt erwartete ich, dass du einen Plan verfolgst und auf Änderungen reagierst. Wenn dieses Vorgehen in der Prüfungsleistung kaum sichtbar wurde, wirkte sich das auf die Note aus. Deine eigene Arbeit und fachliche Tiefe erkennbar machen Aus deinen Unterlagen muss hervorgehen, welchen Teil des Projekts du selbst umgesetzt hast und welche technischen Aufgaben du dabei gelöst hast. Bei Projekten, in denen du eine Anwendung entwickelst, erwarte ich einen entsprechenden Umfang an selbst geschriebenem Code. In den besprochenen Prüfungen lag meine Erwartung bei mehreren hundert Zeilen. Bei einigen SAP- und ERP-Projekten entfiel viel Zeit auf Analysen oder das Konfigurieren vorhandener Software. Für ein Projekt, das eine Anwendung erstellen soll, musst du zeigen, wie du Logik in Code abbildest. Ein Abschlussprojekt, dessen Aufgabe ausdrücklich darin besteht, ein Pflichtenheft zu erstellen, ist ebenfalls legitim. Technologien im Fachgespräch erklären können In fünf Projekten wurde REST eingesetzt. Auf meine Frage konnte eine Person die Abkürzung Representational State Transfer nennen. Bereite dich darauf vor, die Grundlagen der Technologien zu erläutern, auf denen dein Projekt beruht. Bei REST gehören dazu die Bedeutung des Begriffs und die HTTP-Methoden GET, POST, PUT und DELETE samt ihrer Zuordnung zu CRUD-Operationen. Wenn deine gesamte Architektur auf REST beruht, kann auch Roy Fieldings Dissertation als Ursprung des Ansatzes eine Frage im Fachgespräch sein. JSON kam ebenfalls häufig vor. Du solltest erklären können, was das Format ist und warum es für deinen Einsatzzweck passt. Dazu gehört, seine Eigenschaften sowie Vor- und Nachteile im Verhältnis zu XML zu kennen. In einem Projekt wurde JSON innerhalb einer CSV-Datei gespeichert, was Fragen zum gewählten Format aufwarf. Eigenschaften deiner Programmiersprache kennen Für das Fachgespräch brauchst du grundlegendes Wissen über die Sprache, mit der du arbeitest. Besonders häufig fragte ich nach der Typisierung. In einem Projekt mit Java im Backend und JavaScript im Frontend fehlte dazu das nötige Wissen. Java: Im besprochenen Beispiel gehörten Objektorientierung sowie starke und statische Typisierung zu den erwarteten Grundlagen. JavaScript: Hier waren das prototypbasierte Modell sowie schwache und dynamische Typisierung relevant. Prüfe beim Vorbereiten, ob du deinen Quelltext einer anderen Person fachlich erklären kannst. Das gilt auch für Code, den du aus dem Internet übernommen hast. Häufige Fragen vorbereiten Mit dein:er Berufsschullehrer:in und dein:er Ausbilder:in kannst du mögliche Fragen für das Fachgespräch durchgehen. Weitere Erfahrungsberichte findest du in Foren; ich habe dazu auch eine Podcast-Reihe veröffentlicht. Bereite dich auf Grundlagen der Objektorientierung und auf Datenbanken vor. Ebenso gehören Datenstrukturen, Programmierung und Datenschutz zu den naheliegenden Themen. Verarbeitet dein Projekt beispielsweise Namen oder Gehaltsdaten von Mitarbeiter:innen, solltest du Fragen zum Datenschutz fachlich beantworten können. Den Code im Anhang verstehen In den Projekten von 2015 sah ich kaum rein funktionale Programme. Funktionale Sprachelemente tauchten jedoch häufig auf, etwa Lambdas in Java 8 oder LINQ in C#. Auch Funktionen als Parameter oder Rückgabewerte und Generics kamen vor. Jedes Element deines eingereichten Codes kann im Fachgespräch aufgegriffen werden. Ein Beispiel aus meinen Prüfungen war ein using-Block in C#: Beim Verlassen des Blocks wird die Dispose-Methode aufgerufen, damit die betreffende Ressource freigegeben wird. Der/die Prüfungsteilnehmer:in konnte diese Bedeutung des selbst verwendeten Schlüsselworts kaum erläutern. Alles,...