Rückblick auf die Projektdokumentationen der Sommerprüfung 2022 (Fachinformatiker:in Anwendungsentwicklung) – IT-Berufe-Podcast #175

Rückblick auf die Projektdokumentationen der Sommerprüfung 2022 (Fachinformatiker:in Anwendungsentwicklung) – IT-Berufe-Podcast #175

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.
1 Stunde 11 Minuten

Beschreibung

vor 3 Jahren

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

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

Kommentare (0)

Lade Inhalte...

Abonnenten

15
15