Die noch fehlenden Teile der IHK-Sommerprüfung 2018 -
Projektdokumentationen und Fachgespräche - bespreche ich in der
einhundertfünfundzwanzigsten Episode des
Anwendungsentwickler-Podcasts. TL;DR Bei der IHK-Sommerprüfung 2018
habe ich häufig Projektarbeiten gelesen, deren methodisches
Vorgehen kaum erkennbar war. Für deine Projektdoku brauchst du klar
erfasste Anforderungen und einen begründeten Entwicklungsprozess,
während passende Diagramme dein Projekt verständlich machen. Im
Fachgespräch musst du die eingesetzten Technologien erklären können
und fachliche Grundlagen beherrschen; dazu gehören auch Datenschutz
und kaufmännische Themen wie die Kostenrechnung. Kapitelmarken
[00:00:01] Hinweise zum Fachgespräch [00:00:37] Rückblick auf die
IHK-Sommerprüfung 2018 [00:01:37] Unterschiedliche Projektthemen
und Technologien [00:02:31] Methodisches Vorgehen in der
Projektarbeit [00:05:17] Quelltext lesbar in die Doku einfügen
[00:07:07] Agile Entwicklungsprozesse beschreiben und begründen
[00:09:19] Amortisation aus der passenden Perspektive berechnen
[00:10:53] Projektumfeld und interne Begriffe erklären [00:13:01]
Anforderungen erfassen und priorisieren [00:14:36] Architektur und
Oberflächen visuell darstellen [00:16:38] Stundensatz und Kosten
des eigenen Projekts [00:18:44] Projektdoku gegenlesen lassen
[00:19:35] Den Betrieb knapp und projektbezogen vorstellen
[00:21:41] Grundlagen im Fachgespräch [00:23:36] Datenschutz und
IT-Sicherheit [00:24:59] Lambda-Ausdrücke und funktionale
Programmierung [00:25:54] AJAX und asynchrone Aufrufe [00:27:54]
REST und vertiefende Schnittstellenfragen [00:29:08] Vertraute
Technologien für das Prüfungsprojekt wählen [00:30:00]
Betriebsabrechnungsbogen und Kostenrechnung [00:31:08] Funktionale
Anforderungen und Softwarequalität [00:32:18] TypeScript und
Typisierung [00:33:14] Frameworks und Annotationen verstehen
[00:33:52] Entwurfsmuster erklären [00:35:50] Domain-Driven Design
im Fachgespräch [00:37:50] Rückblick auf wiederkehrende
Prüfungsfehler [00:38:52] Shownotes und Kommentare [00:39:14]
Newsletter und kostenlose Checklisten Inhalt Projektdokumentationen
Fehlende Methodik bleibt das Hauptproblem vieler Projektarbeiten.
Code auf schwarzem Hintergrund in der Dokumentation geht gar nicht.
"Agil" ist das neue "wir wissen nicht, was wir tun". Bei der
Amortisationsrechnung werden häufig fälschlicherweise interne
Kosten mit externen Zeiteinsparungen verglichen. Interne Begriffe
werden als allgemein bekannt vorausgesetzt und nicht erklärt. Für
mehrere Projekte wurden die Anforderungen nicht sauber aufgenommen.
Stattdessen wurde wohl einfach drauflos programmiert. Gerade bei
komplexen Architekturen oder Oberflächen sagt ein Bild weiterhin
mehr als tausend Worte! Es gibt immer noch Prüflinge, die ihr
Bruttogehalt als alleinige Basis für ihren Stundensatz nehmen.
Einige Dokumentationen wurden offensichtlich in keinster Weise
korrigiert oder auch nur gelesen. Unternehmensvorstellung auf einer
ganzen Seite mit ganzseitiger Grafik der Standorte im Anhang.
Fachgespräch Es hakt oft an den Basics! Klasse/Objekt,
Kardinalitäten, Lasten-/Pflichtenheft. Datenschutz war das
dominierende Thema (dank DSGVO). Grundlagen der funktionalen
Programmierung sind bei den meisten Prüflingen immer noch nicht
vorhanden. Mal abgesehen von Lambda-Ausdrücken. AJAX wird fast
überall benutzt, aber die Abkürzung kennt kaum jemand. Asynchrone
Programmierung wird eingesetzt, ohne sie erklären zu können. Häufig
wird synchron mit parallel durcheinandergebracht. REST bleibt
weiterhin eine zentrale Komponente vieler Projekte, aber kann
ebenfalls nur selten korrekt erklärt werden. Viele Prüflinge setzen
Technologien für ihr Projekt zum ersten Mal ein. Tiefergehende
Fragen können daher meist nicht beantwortet werden. Der
Betriebsabrechnungsbogen ist vielen Prüflingen nicht bekannt.
Funktionale und nicht-funktionale Anforderungen waren oft nicht
bekannt. Typescript scheint sich für die Frontend-Entwicklung zu
etablieren. Aber dann sollte man auch erklären können, warum man es
einsetzt. Viele Frameworks -> viele Annotationen -> viel
Magie -> viele unerklärliche Abläufe. Wer viele Pattern
einsetzt, sollte sie auch erklären können. Und auch die Grundidee
von Pattern an sich. Domain Driven Design ist toll. Wenn man es
erklären kann. Literaturempfehlungen Da ich erneut so ziemlich alle
erdenklichen Themen angerissen habe, kann ich mal wieder nur das
IT-Handbuch für Fachinformatiker* von Sascha Kersken empfehlen.
*(direkt beim Rheinwerk-Verlag bestellen*) Links Permalink zu
dieser Podcast-Episode RSS-Feed des Podcasts Berechnung des eigenen
Stundensatzes in der Projektdokumentation Zusammensetzung des
Stundensatzes - Häufige Fragen im Fachgespräch Zusammenfassung
Erfahrungen aus der IHK-Sommerprüfung 2018 Bei über 20 Prüflingen
habe ich 2018 sehr unterschiedliche Projekte gesehen, die auf das
jeweilige Unternehmen zugeschnitten waren. Die Bandbreite reichte
von Java und C# bis zu TypeScript oder Visual Basic. Häufig gingen
Punkte verloren, weil aus der Projektdoku kaum hervorging, wie die
Software planvoll entwickelt wurde. Auch im Fachgespräch zeigten
sich wiederkehrende Lücken. Dein Vorgehen in der Projektdoku zeigen
Eine der Arbeiten enthielt 25 Seiten Quelltext im Anhang, während
Belege für das methodische Vorgehen fehlten. Deine Doku muss
nachvollziehbar machen, wie du dein Projekt geplant hast und wie du
beim Entwickeln vorgegangen bist. Halte fest, welche Ressourcen du
brauchst und wie du deine Arbeit zeitlich planst. Erfasse die
Anforderungen, bevor du die Software entwirfst. Zeige mit passenden
Modellen, wie du Abläufe oder Datenstrukturen durchdacht hast.
Dafür kommen beispielsweise Aktivitätsdiagramme oder ein ER-Modell
infrage. Beschreibe deinen Entwicklungsprozess und begründe, warum
er zu deinem Projekt passt. Fehlen zusätzlich die Doku für
Benutzer:innen und die Doku für Entwickler:innen, wirkt sich das
auf die Note aus. Anforderungen aufschreiben und priorisieren In
mehreren Arbeiten waren die Anforderungen auf wenige Sätze
beschränkt. Schreibe auf, was deine Anwendung leisten soll und
welche Qualitätsanforderungen gelten. Du kannst dafür ein
Lastenheft und ein Pflichtenheft erstellen oder mit User Stories
arbeiten. Prioritäten lassen sich etwa über Muss-, Soll- und
Kann-Kriterien festlegen. Anhand dieser Vereinbarungen kann dein:e
Auftraggeber:in später prüfen, ob du das Projekt erfolgreich
umgesetzt hast. Ein Pflichtenheft kann zum Vertragsbestandteil
werden und damit helfen, Streit über den vereinbarten Umfang zu
vermeiden. Den Entwicklungsprozess konkret beschreiben Wenn du agil
arbeitest, musst du den gewählten Prozess mit seinen Regeln
beschreiben. Scrum und Feature Driven Development sind konkrete
Vorgehensweisen. Bei Extreme Programming gehören beispielsweise
Test Driven Development und Pair Programming zu den Praktiken. Für
die damals vorgesehenen 70 Projektstunden solltest du prüfen, wie
sich dein Prozess im verfügbaren Zeitrahmen durchführen lässt.
Bereits nach einer Iteration kann das Projekt weitgehend vorbei
sein. Auch beim Wasserfallmodell muss erkennbar sein, wie du die
Phasen in deinem Projekt durchläufst. Dein Projekt verständlich
darstellen Das Umfeld knapp erklären Beschreibe dein Unternehmen in
wenigen Sätzen und erläutere anschließend das Umfeld, das für dein
Projekt relevant ist. Interne Softwarebezeichnungen und Abkürzungen
brauchen eine Erklärung, damit ich als Prüfer:in nachvollziehen
kann, woran du arbeitest. Halte außerdem fest, welche Aufgaben dein
Unternehmen übernimmt und welche bei deinen Kund:innen liegen.
Unklare Rollen erschweren es, den Zweck des Projekts und seine
Wirtschaftlichkeit zu bewerten. Wie ausführlich du deinen Betrieb
vorstellst, richtet sich danach, welche Informationen zum
Verständnis des Projekts erforderlich sind. Architektur und
Oberflächen zeichnen Wenn mehrere Systeme zusammenarbeiten, zeigt
eine Architekturskizze, wo welche Software läuft und wohin Daten
übertragen werden. Dafür eignet sich ein UML-Komponentendiagramm;
auch eine einfache Zeichnung mit Pfeilen kann die Zusammenhänge
sichtbar machen. Für eine geplante Oberfläche bietet sich ein
Mock-up an. Eine eingescannte Handskizze kann bereits zeigen, wie
ein Dialog aufgebaut ist. Solche Darstellungen gehören auch in
deine Präsentation, wenn sie dein Projekt verständlich machen.
Quelltext lesbar setzen Setze Code als Text auf weißem Hintergrund
in einer Monospace-Schrift, beispielsweise Courier New. Dabei haben
alle Zeichen dieselbe Breite. Farben zum Hervorheben der Syntax
sind möglich. Screenshots mit schwarzem Hintergrund verbrauchen
beim Drucken viel Toner und erschweren es mir, Anmerkungen am Code
zu machen. Die Doku gegenlesen lassen In einigen Arbeiten fand ich
zahlreiche Sprachfehler und abgebrochene Sätze. Lass eine andere
Person prüfen, ob deine Sätze verständlich und grammatisch korrekt
sind. Sie kann auch auf Rechtschreibung und Satzzeichen achten,
ohne dein Projekt fachlich beurteilen zu müssen. Schwer lesbare
Inhalte erschweren die Bewertung und beeinflussen die Note. Kosten
für dein konkretes Projekt berechnen Frage im Rechnungswesen deines
Unternehmens nach einem passenden Stundensatz. Darin müssen neben
deiner Ausbildungsvergütung auch Lohnnebenkosten und Gemeinkosten
berücksichtigt werden. Die Beispielrechnungen in meinen Vorlagen
sind unvollständig und müssen an dein Projekt angepasst werden.
Wenn du ein Teilprojekt umsetzt, berechne dessen Kosten und
Wirtschaftlichkeit. Die Zahlen des Gesamtprojekts liefern dafür
keine ausreichende Grundlage. Bei der Amortisationsrechnung muss
die Perspektive durchgehend zusammenpassen: Für ein internes
Projekt berechnest du, wann die internen Einsparungen die internen
Projektkosten ausgleichen. Bei einem verkauften Produkt rechnest du
aus Sicht deines Unternehmens mit den Verkaufserlösen. Je nach
Geschäftsmodell kann dafür eine bestimmte Zahl verkaufter Lizenzen
erforderlich sein. ...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.