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.
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