Einen Rückblick auf die Projektdokumentationen (Fachinformatiker:in
Anwendungsentwicklung) zu Teil 2 der gestreckten Abschlussprüfung
im Sommer 2022 gibt es in der einhundertfünfundsiebzigsten Episode
des IT-Berufe-Podcasts. TL;DR Aus meinen Erfahrungen mit der
Sommerprüfung 2022 habe ich Hinweise für deine Projektdokumentation
zusammengestellt: Dein Projekt muss fachlich verständlich sein,
wobei du deine Entscheidungen und deine eigene Arbeit
nachvollziehbar beschreibst. Bei der Kostenplanung gehören die
betrieblichen Stundensätze ebenso dazu wie laufende Kosten und die
Zeit weiterer Beteiligter. Zeige konkrete Ergebnisse deiner
Qualitätssicherung und setze Technologien ein, mit denen du
vertraut bist. Für deine Prüfung gelten die Vorgaben deiner IHK und
deiner Prüfer:innen. Kapitelmarken [00:00:00] Einstieg und
Rückblick auf die Sommerprüfung 2022 [00:02:30] Meine Erfahrungen
und die Vorgaben deiner IHK [00:04:02] Fachliche Inhalte und
formale Details bewerten [00:05:28] Messaging und Microservices
passend einsetzen [00:08:34] Das Projekt mit Use-Case-Diagrammen
verständlich machen [00:09:51] ER-Modell und Tabellenmodell richtig
benennen [00:11:48] Technologien vor dem Abschlussprojekt
kennenlernen [00:13:15] Anhänge im Fließtext erklären und
referenzieren [00:16:34] Blocksatz und Gliederungstiefe [00:19:49]
Kapitel mit Inhalt füllen und Word-Verweise prüfen [00:21:23]
Stundensätze aus Sicht des Betriebs bestimmen [00:25:57]
Stundensätze konsistent verwenden [00:27:58] Firmengeheimnisse und
Datenschutz [00:29:44] Laufende Kosten berücksichtigen [00:31:52]
Arbeitszeit und Kosten weiterer Beteiligter [00:34:48]
Entscheidungen anhand der Anforderungen begründen [00:37:15] Eigene
Leistung sprachlich erkennbar machen [00:38:21] Nutzwertanalysen
nachvollziehbar bewerten [00:39:52] Vorgehensmodell und
Anforderungen festhalten [00:40:58] Lastenheft und Pflichtenheft
[00:43:48] Aussagekräftige Anforderungen und technische Angaben
[00:46:26] Inhalte innerhalb der Seitengrenze auswählen [00:47:19]
Zeitplanung und Qualitätssicherung [00:49:10] Projektspezifische
Inhalte statt allgemeiner Erklärungen [00:51:16] Standardisierte
Diagramme verwenden [00:52:32] Soll-Ist-Vergleich nachvollziehbar
rechnen [00:55:05] SSH-Sicherheit und Schlüsselprüfung [00:57:29]
Aufgaben in der Detailplanung aufteilen [00:59:05] Low-Code im
Abschlussprojekt Anwendungsentwicklung [01:00:34] REST-APIs
absichern [01:02:07] REST-Ressourcen und HTTP-Methoden [01:04:48]
Code-Review-Ergebnisse konkret dokumentieren [01:07:34] Eigene
Arbeit durch sichtbare Artefakte belegen [01:08:47] Weiterführende
Beiträge und Ausblick [01:09:35] Newsletter passend zum
Ausbildungsstand Inhalt Projektdokumentationen Sommer 2022
(Fachinformatiker:in Anwendungsentwicklung) Disclaimer: Meine
Meinung ist nicht stellvertretend für alle Prüfungsausschüsse in
Deutschland. Ich schaue oft auch auf die formellen Details, aber
wichtiger sind natürlich immer die fachlichen/technischen Inhalte.
Einzelne Punkte auf der folgenden Liste führen nicht zwangsläufig
zu Punktabzug bei der Note, aber oft treten mehrere Punkte
gemeinsam auf, was dann einen Punktabzug rechtfertigt. Viele
"Probleme" mit den Projektdokumentationen gelten 1-zu-1 in allen
IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun
haben. Allgemeines Messaging wird in mehreren Projekten eingesetzt.
Nur wenige Use-Case-Diagramme gesehen. -> Was macht das System
eigentlich? Oft wurde ein Tabellenmodell ER-Modell genannt.
Frameworks oder gar Programmiersprachen waren vor der
Projektdurchführung nicht bekannt. Formalia Abbildungen wurden mit
ihrem Namen referenziert, anstatt mit der Seitenzahl. Einige
Dokumentationen waren im Flattersatz gesetzt. Eine Dokumentation
hatte 5 (!) Ebenen im Inhaltsverzeichnis, also z.B. bis Kapitel
4.2.4.1.2. Ein Kapitel bestand nur aus einem (!) Aufzählungspunkt.
"Textmarke nicht definiert" im Dokument. Stundensatzberechnung Es
wurden verschiedene Stundensätze für einzelne Mitarbeiter
angegeben, dann aber nur mit einem einheitlichen gerechnet. Der
Stundensatz wurde oft nur aus der Azubivergütung berechnet (z.B.
Vergütung / 20 / 8 -> 6 EUR/h). Ein Prüfling hat explizit
geschrieben, dass der Stundensatz sich nur aus der Azubivergütung
berechnet, setzt dann aber 75 EUR/h an. Oft wird der Datenschutz
als Begründung genutzt, die echten Stundensätze nicht nennen zu
können. Kosten Es wurden 500 EUR/Monat als laufende Kosten für
einen (!) Server angesetzt. Die Abnahme wurde mit 3h eingeplant,
aber nur mit 1h in den Kosten aufgeführt. Stunden des Fachbereichs
tauchten nicht in den Kosten auf. Ein Prüfling hat die Stunden
anderer Mitarbeiter mit in seine 70h aufsummiert. Begründung von
Entscheidungen Begründung für technische Entscheidung: "Ich soll
das so machen." Ein Prüfling hat durchgängig geschrieben, dass
"man" das Projekt umgesetzt hat. Es gab eine Nutzwertanalyse, bei
der die Eigenentwicklung in allen (!) Kriterien die maximale
Punktzahl hatte. Anforderungsermittlung Im Lastenheft wurde vom
Kunden angeblich Java 11 und Messaging gefordert. Ein Lastenheft
bestand nur aus zwei Sätzen und das dazu passende Pflichtenheft war
"nicht nötig". Die Programmiersprache wurde in einer gesamten
Dokumentation nicht genannt. Fehlende oder überflüssige Inhalte
Eine Dokumentation enthielt keinerlei Zeitplanung, Phasen oder
Prozess. Die Qualitätssicherung fehlt oft komplett (z.B. Testen,
CI/CD, Reviews). Auf 1/2 Seite wurde Scrum im Detail erklärt bzw.
auf einer ganzen Seite REST. Sonstiges Ein Prüfling hat sich eigene
Diagrammformen ausgedacht, anstatt einfach UML zu nutzen. Beim
Soll-Ist-Vergleich wurde Soll - Ist gerechnet. Security wurde bei
SSH absichtlich ausgeschaltet. In einer Detailplanung war ein Block
23h lang. Es wurde mit einer Low-Code-Plattform gearbeitet, für die
es eigentlich nichts zu programmieren gab. REST wird inzwischen
sehr oft verwendet, aber die wenigsten Prüflinge wissen, wie man
die APIs absichert. REST-APIs sehen oft sehr seltsam aus ("GetById"
im Path). Positiv aufgefallen Das Code-Review hat tatsächlich auch
mögliche Optimierungen ergeben (Namen, Struktur). Links Permalink
zu dieser Podcast-Episode RSS-Feed des Podcasts
Datenbankmodellierung (Lernzielkontrolle zum relationalen
Tabellenmodell) Datenbankmodellierung (Lernzielkontrolle zum
Entity-Relationship-Modell) Welche Programmiersprache du für dein
Abschlussprojekt verwenden solltest Berechnung des eigenen
Stundensatzes in der Projektdokumentation (FAQ) Datenschutz vs.
Datensicherheit vs. Datensicherung Nutzwertanalyse in der
Projektdokumentation Lasten- und Pflichtenheft in der
Projektdokumentation Scrum Einführung in Continuous Integration
Unit-Tests - Häufige Fragen im Fachgespräch Elena Hollen über Code
Reviews und Extreme Programming Zusammenfassung Woher meine
Hinweise kommen Als Prüfer für Fachinformatiker:innen
Anwendungsentwicklung bei der IHK Oldenburg habe ich
Projektdokumentationen aus der Sommerprüfung 2022 gelesen. Viele
der dabei aufgefallenen Punkte betreffen auch andere IT-Berufe.
Meine Hinweise beruhen auf diesen Erfahrungen; für deine Prüfung
sind die Vorgaben deiner IHK und deiner Prüfer:innen maßgeblich.
Die geprüften Projekte wurden noch nach der alten Prüfungsordnung
mit 70 Stunden durchgeführt. Für Anwendungsentwicklungsprojekte
nach der neuen Ordnung stehen 80 Stunden zur Verfügung. Bei meiner
IHK war der Fließtext auf 15 Seiten begrenzt, während die gesamte
Dokumentation einschließlich Anhang häufig etwa 50 Seiten umfasste.
Dein Projekt verständlich beschreiben Wer deine Dokumentation
liest, muss verstehen können, welche fachliche Aufgabe dein System
erfüllt. Ein Use-Case-Diagramm zeigt die beteiligten Akteur:innen
und die Anwendungsfälle auf einer abstrakten Ebene. Damit schaffst
du einen Einstieg in dein Projekt. Nenne die verwendete
Programmiersprache ausdrücklich, sodass deine Prüfer:innen sie
direkt erkennen können. Beschreibe außerdem, wie du vorgegangen
bist und welche Projektphasen du geplant hast. Bei Datenmodellen
kommt es auf die passenden Begriffe an: Ein
Entity-Relationship-Modell beschreibt Daten abstrakt und unabhängig
davon, wie du später eine Datenbank aufbaust. Ein Tabellenmodell
zeigt die Tabellen einer relationalen Datenbank. Es lässt sich aus
einem ER-Modell ableiten. Auch andere Datenbankformen kommen
infrage, etwa Dokumentendatenbanken oder Key-Value-Stores. Wenn du
ein Diagramm benennst, sollte der Name zur gezeigten
Darstellungsform passen. Technologien kennen und passend auswählen
Bevor du mit deinem Abschlussprojekt beginnst, solltest du die
eingesetzten Technologien bereits kennen und praktisch ausprobiert
haben. Das gilt besonders für die Programmiersprache und zentrale
Frameworks. Plane dafür genügend Vorlauf ein. Bei mehreren
Projekten fiel mir auf, dass Messaging eingesetzt wurde, ohne den
zusätzlichen Aufwand ausreichend zu berücksichtigen. Eine Message
Queue, beispielsweise mit RabbitMQ, kann Systeme entkoppeln und
Nachrichten asynchron weitergeben. Zur Entscheidung gehört, dass du
dich auch mit möglichen Ausfällen des Brokers und der angebundenen
Dienste beschäftigst. Wenn du sehr kleine Dienste auf mehrere
Microservices verteilst, entstehen zusätzliche Komponenten, deren
Betrieb du berücksichtigen musst. Begründe deshalb anhand deiner
Anforderungen, welchen Beitrag die Architektur zu deinem Projekt
leistet. Das gilt ebenso für Single-Page-Apps und andere technische
Ansätze. Bei Low-Code-Plattformen sehe ich für das Abschlussprojekt
in der Anwendungsentwicklung ein Problem: Deine Prüfer:innen müssen
beurteilen können, ob du programmieren kannst. Wähle ein Projekt,
in dem diese Fähigkeit sichtbar wird. Entscheidungen
nachvollziehbar begründen Aus deiner Dokumentation sollte
hervorgehen, warum du eine Lösung gewählt hast und wie sie zu den
Anforderungen passt. Bei betrieblichen Vorgaben gehören die
verantwortliche Stelle und der Hintergrund dazu. Eine Formulierung
wie "Ich soll das so machen" lässt diese
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.