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.

Probeabo bei Audible (Affiliate)

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

Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

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

  1. Tim sagt:

    Hallo Stefan,

    gute Folge. Das mit dem Lastenheft und der Angabe der Programmiersprache kann ich SO nicht direkt bestätigen.
    Ich arbeite z. B. für eine Softwareschmide und wir haben von einem großen Kunden die Anforderung, dass das was wir entwickeln in einem bestimmten Framework z.B.(gab noch mehr) gemacht werden muss, da der Kunde es später selbst weiterentwickeln/betreuen will. Also gibt es schon Fälle wo fachliche Details im Lastenheft stehen. 😉

    vg, Tim

  2. Tray Knots sagt:

    Interessante Episode. Kleine Anmerkung, bei uns in der Firma haben wir schon mehrfach Kunden gehabt, die die Anforderung „Programmiersprache“ hatten. Wir hatten unser Framework und Skeleton in Scala und haben dann Kunden gehabt die auf PHP bestanden.

    Die Kunden haben argumentiert, dass in ihrer Erfahrung sie keine Scala Programmierer finden werden. Und sie wollten die Option haben hier auf interne Entwicklung oder ein anderes Entwicklungshaus umzusteigen.

    Also, de facto, Kunden bestehen öfters auf bestimme Technologien. Wahrscheinlich noch mehr wenn Ausschreibungen und Buzzwords ein Teil der ganzen Geschichte sind. Wieso nutzt man realistische eine Blockchain? Naja, ne SQL Datenbank wäre besser, aber die Förderung gibt nur Geld für Projekte auf Blockchaintechnologie.

  3. Stefan Macke sagt:

    Hallo Tim, danke für dein Feedback! So habe ich es ja auch in der Episode erwähnt. Es gibt halt immer auch mal technisch interessiertere Kund:innen. Allerdings war das beim betrachteten Projekt leider nicht so.

  4. Stefan Macke sagt:

    Hallo Tray, danke für die Ergänzung mit der Förderung der Blockchains. Daran habe ich nicht gedacht! 😀

  5. Marco sagt:

    Hast du eine Quelle für die Argumentation mit dem Flattersatz? Ich kenne nämlich das Argument mit den Augen genau für und nicht gegen den Flattersatz. Edward Tufte nutzt diesen etwa in seinen Büchern.

  6. Sebastian sagt:

    Ich befinde mich derzeit in einer Umschulung zum Fachinformatiker für Anwendungsentwicklung und bin jetzt in meiner 4. Woche der betrieblichen Lernphase, zu dem Thema das die Programmiersprache vor dem Projekt nicht bekannt ist muss ich einfach mal meinen Senf geben: Laut deiner Aussage sind 6 Monate nicht genug Zeit um etwas „production ready“ umzusetzen, da man sich ja erst mit einer Programmiersprache auseinander setzen muss. Aber bei uns ist es teilweise der Fall, dass die betriebliche Lernphase insgesamt nur 6 Monate geht und wir wie z.B. ich jetzt nur einen Monat haben bis der Antrag eingereicht werden muss.
    Natürlich „lernen“ wir Programmiersprachen in der Umschulung, aber da werden viele Sprachen von Grund auf erklärt, für 2 bis 4 Wochen und in der Zeit werden aber nur Grundlagen vermittelt.
    Leider ist es für uns Umschüler nicht anders möglich, als uns erst im Praktikum mit den Programmiersprachen und Frameworks des Betriebs richtig auseinander zu setzen.
    Werden wir dadurch anders bewertet als normale Auszubildende? Wahrscheinlich nicht.
    (Soll jetzt nicht böse sein, ist nur etwas das mir aufgefallen ist und für mich etwas doof ist)

  7. Stefan Macke sagt:

    Hallo Marco, zu Blocksatz vs. Flattersatz gibt es durchaus verschiedene Aussagen. Siehe:

    Der Blocksatz gewährleistet einen eher ungestörten, flüssigen Lesevorgang.
    Leserlichkeit

    Bei kurzen Satzbreiten von maximal vier Worten ist der Flattersatz dem Blocksatz vorzuziehen.
    Satzbreite

    Im einspaltigen Satz findet er mehr aus vermeintlich ästhetischen Gründen Anwendung, aber im mehrspaltigen Satz ist er [der Blocksatz] unverzichtbar […]
    Blocksatz

    Also kann wohl am Ende jeder das nehmen, was ihm gefällt! 😀 Und ich würde auch keinem Prüfling Punkte abziehen, weil er/sie die falsche Wahl getroffen hat.

  8. Stefan Macke sagt:

    Hallo Sebastian, nein, Umschüler:innen werden genauso bewertet wie „normale“ Azubis. Wenn das Erlernen einer Programmiersprache wegen der zeitlichen Gegebenheiten in der Umschulung nicht in der nötigen Tiefe möglich ist, musst du halt dein Bestes geben! Ihr schreibt die Prüfungen ja auch recht fix hintereinander. Da ist halt alles nicht so ganz passig zu den üblichen Prüfungsabläufen für Azubis. Und ich sage ja nicht, dass es komplett unmöglich ist, ein gutes Projekt mit einer bisher unbekannten Programmiersprache umzusetzen. Meiner Erfahrung nach ist es aber meist eine schlechte Idee!

  9. Kritiker (= sagt:

    Wieso ist die IHK so streng?
    Ich will AE werden. Ich gehe nicht zu Kunden, ich sage „Hey hab ne Idee, sei du lieber leise, ich entwickel ein Programm für dich. Die Kunden kommen zu mir und sagen mir, was reingehört und wie was aussehen soll. Sogar unser Lehrer war sauer auf die IHK und das war wegen der neuer verordnung. Wenn die IHK so weiter macht, wird es noch mehr Personal mangel in der IT geben. Ich mag Ihren Podcast sehr und habe auch den Teil mit dem Neuen Verordnung angehört, aber es ist deutlich schwerer geworden.
    Ah und vergessen zu sagen, es gibt auch Leute, die in einem Betrieb arbeiten und nichts dafür können, wenn das Betrieb nicht nachdem Rahmenplan geht.
    Ich habe immer noch keine Idee für mein Projekt

  10. Stefan Macke sagt:

    Ich spreche nicht für „die IHK“, sondern nur für mich. Was genau findest du denn streng?

    Zur Themenfindung für dein Projekt schau mal hier: Themenfindung für das Abschlussprojekt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax